On the Stovepipe Systems blog Iltar van der Berg shares some thoughts about rethinking form development and how moving from composition over inheritance model can help make working with Symfony forms easier.

In one of my previous blog posts, Avoiding Entities in Forms, I've shown how to decouple your forms from your entities. Afterwards I got feedback and most of it was about the lack of examples and the flow, when to fill your data and how to get this back in the entity. However, often I notice that developers design forms based on their entities. This can lead to complex forms because you're confined to a strict set of properties. Developers often get struck with unmapped fields and form events to work their way around those limitations.

With Symfony Forms I highly recommend to follow the composition over inheritance principle. Small form types are easier to re-use and make it less complex to build forms. Moreover, this allows small data objects to have specific goals with validation for their specific case, rather than complex validation groups.

He starts with an example user story, defining a need for a form that allows users to post comments on blog posts. He starts on this simple form, defining the "bare minimum" the form requires and creating a class/entity to match. He then talks about what happens when the business need changes and they want a checkbox too. Since he created the form based on the "composition" idea (not defined by the database structure) he could pretty easily update it with this new field and add a bit of extra handling.

Patrick Louys has written up a new post to his site that gets into detail about one of the SOLID development principles - the Open/Closed Principle - and how it can be applied in PHP.

I am a big proponent of the SOLID principles. But one of the principles - the open/closed principle - is often misunderstood. [...] Bertrand Meyer stated it first in his book "Object-Oriented Software Construction" in 1988. The problem with it is that some people see the word extension and they think that it is talking about inheritance (because PHP uses the extend keyword for inheritance).

He goes on to talk about a comment from Reddit and uses it as an illustration about the "extension" misconception and the commentor advocating against dependency injection. He then gets into some code showing a "Logger" class that writes to the filesystem and trying to extend it to add functionality. He covers how using a dependency injection container can help some of the inheritance issues (using a "base" class) but ultimately steps back to provide another solution. The re-applies both the open/closed principle and dependency injection to create a system where the "base" Logger class is a dependency rather than a parent class.

In this post to his site James Lewis makes the suggestion that you consider composition over inheritance when it comes to writing your object-oriented PHP. That is, using PHP's traits functionality to compose interfaces with only the functionality needed, not other possibly useless things.

So what does “composition over inheritance” mean? [...] Lets dive into an example written in PHP to help us better understand composition over inheritance. [...] Almost all modern programming languages have a way of dealing with composition, PHP has Traits. Traits where introduced into PHP at version 5.4 and the PHP docs describes traits as a mechanism for code reuse.

He starts with an example of using inheritance to create new "animal" types but points out that this can lead to extra functionality as sometimes your Robocat just doesn't need to eat. He then introduces traits as a way around the issue, creating traits for each piece of functionality and using PHP's use statement to include only the ones needed for that particular kind of object.

Ross Tuck has posted a new article to his site today talking about how he uses traits in his applications and where he sees them having the most value.

Recently, a few folks asked about a trait in a new project I wrote. Right around the same time, Rafael Dohms showed me his new talk about complex cognitive processes we don’t notice. Because my brain is a big mushy sack, the two blended together. The result was this post, which tries to capture how I use traits but also how I decide to use them in the first place.

He starts off with a bit of talk about leverage versus abstraction and how the concepts relate to code. He includes a brief example of each and points out that, while each is good, abstraction tends to be more useful. He then applies this back to the world of traits, how they compare to the use of normal static methods and how they have an advantage of encapsulation without oversharing. He suggests that assertions are more fit as static methods and that traits are a better fit in cases where multiple inheritance is needed. He also touches in interfaces in traits and his opinion on when is the best time to use them.

On the Graze.com Tech blog there's a recent post about sharing logic between controllers with the help of traits. He makes use of the traits functionality in PHP to abstract out functionality common to multiple controllers (in his case, common user functionality).

There have been a few times I have come across a situation where I need to share some logic between controllers but it hasn't been as clear cut as abstracting that logic out into a library. I've been pondering the best way to tackle this problem and would like to share my thoughts.

In his example he shows how two different controllers, the Account and Signup controllers, both need to be able to look up an address and perform some simple checks on the results. The logic is duplicated so he first tries to move it out to an abstract controller but notes that it's not the most ideal solution. Next he tries moving the code out into a library but finds issues with separating out the necessary concerns. Finally he moves the logic into a trait (AddAddressTrait) that contains it and allows the direct integration of his "lookupPostalCode" method into the controller without inheritance or other design issues.

Mathias Verraes has posted some of his thoughts about using "final" in classes and what kind of impression it gives about your code.

I make all my classes final by default. I even configured the templates in my IDE prefix new classes with ‘final’. I’ve often explained my reasoning to people. A blog post is in order! A guiding principle here is Clarity of Intent. [...] The reason we need clean code, is not for the compiler. It’s to help our fellow developers, third parties, and even ourselves in six months time, understand the purpose and the design of our system.

He relates this concept of clean code and clarity back to the SOLID development principles, specifically the "Open/Closed Principle". This principle states that software should be open for extension but not for modification. It suggests that providing a stable, known API is a responsibility of the developer and using things like callbacks and listeners is a better way to extend. He gets into a bit more PHP-specific issues around using "final", including the difficulties that it can cause during testing.

In his new post Allan MacGregor takes a look at a somewhat underused feature of PHP (since 5.4), traits. He talks about how they can help solve multiple inheritance issues and the power they can offer.

Languages like C++ or Python manage this problem by allowing inheritance from multiple classes, Ruby in the other hand uses Mixings to address this issue. Regardless of the technique the problem remains the same; Traits are another approach to this problem and are commonly used in the languages like Perl and Scala.

He includes an example of the standard PHP method for inheritance in classes via the normal "extends" handling. He refactors this into a setup using traits to "override" the single inheritance issues via a "Cat" trait included in the "Tiger" class providing the "roar" method inside the class context.

The best part about traits is that it makes sense from a structural point of view. [...] Traits are an incredible addition to the PHP language and we have only started to touch the surface.

On the Qafoo blog today Kore Nordmann has a new post talking about code reuse through inheritance. He talks about base classes, sharing code and abstraction.

To me, inheritance has two properties: Defining an is-a relationship [and] making it possible to share code between classes by extending from a common base class. The is-a relationship between classes is one thing I like to use inheritance for. [...] The other thing you can use inheritance for is to share code between multiple classes. [...] I personally think that the latter is one of the worst things you can do in object oriented design. Bear with me for a moment and let me try to explain why I think that.

His example of doing it the wrong way is using the Active Record design pattern and how it's usually implemented - storage logic in the base class and business/table logic in the extending class. He then gets into an example that's a bit "smaller" creating diff display functionality and how the "code reuse by inheritance" creeps in a lot in helper methods. He also briefly looks at testing (or not testing) private methods and and the "Depth of Inheritance Tree" metric's recommended value.

In a previous post Anthony Ferrara looked at design patterns and their use (and usefulness) in modern applications. in this new post he continues the series but focuses more on a strategy to move past them related to inheritance.

In my last post, I talked about revisiting the concept of Design Patterns and questioned how useful it is to "learn" them. The conclusion that I came to was that you are better served by focusing on how objects communicate rather than traditional patterns. Well, that's not the only "traditional concept" that I think we should move beyond. So, let's talk about inheritance...

He starts with a bit of definition about what inheritance actually is (for a little context) related to classes, not traits or interfaces. He compares two ideas around this inheritance - the actual implementation of it in the code and the specification of it, the planning a "promise" the structure defines. He discusses the separation of these two ideas and that what matters is that the specification is implemented - how doesn't matter as much. He gets down to the most basic concept behind the idea of inheritance, the idea of a "contract", that defines the "agreement" the implementation puts into practice.

Finally, he gets down to what he calls "the key" behind inheritance and encapsulation of functionality into desecrate parts - behaviors. These allow you to know what kind of functionality comes from which class/object without having to guess. Methods have behaviors and objects are collections of these, combining to make a larger object-centric behavior.

Object Oriented Programming is all about abstraction. Each layer is an abstraction of code below it. Using "types" makes this difficult, because often we don't have real-world analogs to represent each layer. After all, an abstraction is specifically not a type. It's the concept behind it. With behaviors, this comes naturally.

Accessing private class properties via getters and setters is a pretty standard way to write your applications. Unfortunately it can be time consuming to write them for every property your class may have. On 7PHP.com Khayrattee Wasseem has a few ideas (including using PHP's own Reflection functionality) to dynamically create them.

When coding a project, at times (or most of it?) some classes might have more than 3 fields (for whatever reason it suits you). So instead of each time writing and repeating setters and getters (accessor methods), I would like to have a piece of reusable code for all my classes without me ever writing a single line of code for accessors. (‘ever’ as in ‘very very rarely’). Now, we also have to take into consideration that some fields might be only get-able or only set-able – (our re-usable piece of code should cater for this)

He shows two different methods to accomplish this kind of dynamic access, one using traits and the other using normal class inheritance. HE includes the code illustration each solution and talks a bit at the end of each section of why that method might be better than the other.