In this post to his site Matthias Noback makes the argument that, during your normal development, classes should be final by default and only changed if there's a need to extend them.

I recently wrote about when to add an interface to a class. After explaining good reasons for adding an interface, I claim that if none of those reasons apply in your situation, you should just use a class and declare it "final".

[...] For a couple of years now I've been using the final keyword everywhere (thanks to Marco Pivetta for <a href="https://ocramius.github.io/blog/when-to-declare-classes-final/>getting me on track!). When I see a class that's not final, it feels to me like it's a very vulnerable class. Its internals are out in the open; people can do with it what they want, not only what its creator has imagined.

Still, I also remember my initial resistance to adding final to every class definition, and I often have to defend myself during workshops, so I thought it would help if I explained all about it here.

He starts off by talking about the alternative - non-final classes - and some of the issues that can come with it (and class extension). He makes the suggestion that "replacing is better than overriding" and creates less complexity overall. He also answers a question about the use of the "Template Method" design pattern that would allow for improvement from base "skeleton" logic designed to be extended. He covers "composition over inheritance", the use case of extension and how "final" is a better direction.

The Three Devs & A Maybe podcast, hosted by Michael Budd, Fraser Hart, Lewis Cains and Edd Mann, has posted their latest episode: The Power of Composition. In this episode they're joined by guest Scott Wlaschin, a senior software architect and developer with over twenty years of experience.

In this weeks episode we are lucky to have Scott Wlaschin back on the show. We start of discussion by highlighting his most recent talk on composition and some useful analogies to Lego, Brio and Unix. From here we move on to investigate function and type composition, the difference between a paradigm shift compared to simply a syntax one and the advantages of an opinionated language.

This leads us on to mention how within application design pushing the side-effects to the edge and keeping the core domain pure is beneficial. Finally, we touch upon testing in functional languages, experiences whilst consulting and Rich Hickey’s ‘Effective Programs’ talk.

You can listen to this latest episode either using the in-page audio player or by downloading the mp3 directly for listening at your leisure. If you enjoy the show, be sure to subscribe to their podcast and follow them on Twitter to get updates on when the latest shows are released.

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.

On the Symfony Finland site there's a post that gets into the details of one of the new advancements in the Symfony ecosystem recently announced by Fabien Potencier at SymfonyCon Berlin 2016 - Symfony Flex.

The Symfony team has acknowledged this gap in their offering. And at SymfonyCon Berlin 2016 project lead Fabien Potencier announced what is known as Symfony Flex. Details are not precise, as I was not attending conference, but the tag line for Symfony Flex is: "Composition over Inheritance"

In essence it seems that Flex will allow for zero-config installation of Bundles. This is done using a Composer plugin. You will simply install packages with Composer and if the Bundle supports it, Composer will also author the necessary integration code and configuration.

As with any new thing, Flex support will start out pretty limited but as it grows in support the community should help it thrive in the Symfony ecosystem. The first release of the tooling for Flex will be available in early 2017.

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.

On PHPMaster.com today there's a new tutorial posted that wants to provide a guide to walk you through a trio of ideas to help with code/idea reuse in your applications - inheritance, composition and delegation.

The popular belief is that reusing implementation, thus producing DRYer code, boils down to exploiting the benefits that Inheritance provides, right? Well, I wish it was that easy! [...] If you don’t know what path to travel when it comes to reusing implementation, in this article I’ll be doing a humble walk-through on the Inheritance/Composition/Delegation trio in an attempt to showcase, side by side, some of their most appealing virtues and clunky drawbacks.

He starts off with a look at Inheritance, showing with a small code sample showing the creation of an interface and a resulting PDO adapter class implementing it. He also shows the concept of composition, following the ideas of the Adapter pattern. In his Delegation example he shows how to implement the creation of the connection object as a part of the class' creation.

In this new post to his blog, Bence looks at how inheritance is commonly used in PHP applications and how, if not controlled carefully can be something that creates bad habits among PHP developers.

In fact I think that using inheritance all the time is a very big mistake and makes your code hard to maintain and more hard to integrate (the latter is a mistake for application codes and a fatal mistake for libraries). The main problem with inheritance is that if you use it for coupling two classes, then a very important property of the subclass is used up: it's superclass. It is taken, reserved, and it can not be used for anything else furthermore. If you want to connect your subclass to an other class using inheritance, you can't.

He recommends avoiding the typical uses of typical superclass/subclass inheritance unless what you're doing specifically requires it. Working with interfaces, abstract classes and good composition planning is a much better idea.

In a new post to his blog Devis Lucato points out something he noticed when working with objects and anonymous functions/closures - they're not all as they seem.

Both solutions allow to instantiate an anonymous object with properties. They are used as value objects and have no other purpose than storing values, so no logic can be included and they don't come with methods. They can be used as function parameters instead of arrays, for instance. PHP 5.3.0 introduced anonymous functions and closures, so it is now possible to attach functions to these VOs (*). [...] The first thing to notice is that these properties are not methods but callable functions:

In his example, an anonymous function dynamically appended to an object doesn't have access to a property set on the object just one line before. There's a way around it with call_user_func, but it's not practical. His proposed solution is to create a type of Anonymous class that uses the __call method to catch the methods and translate them into calls to call_user_func_array automatically.

Larry Garfield has put together some benchmarks based around a request he had from other developers (the "performance czars") as to how the magic functions in PHP5 would perform in the new environment.

Already, there is talk of how, and if, to leverage PHP 5's object handling now that we don't need to deal with the weirdness of PHP 4's object model. Of course, because it's Drupal, our army of performance czars want to know just what the cost is for object handling, and especially advanced object magic like __get(), __call(), the ArrayAccess interface, and so forth.

He an his tests on a Thinkpad (Intel Core2 Duo 2.2Ghz) running Kubuntu and PHP 5.2.3. They were run two million times benchmarking the different methods for:

• function calls
• __call
• __get
• __set
• iterators (array)
• inheritance
• composition

His results are listed at the end of the post.

Larry Garfield has put together some benchmarks based around a request he had from other developers (the "performance czars") as to how the magic functions in PHP5 would perform in the new environment.

Already, there is talk of how, and if, to leverage PHP 5's object handling now that we don't need to deal with the weirdness of PHP 4's object model. Of course, because it's Drupal, our army of performance czars want to know just what the cost is for object handling, and especially advanced object magic like __get(), __call(), the ArrayAccess interface, and so forth.

He an his tests on a Thinkpad (Intel Core2 Duo 2.2Ghz) running Kubuntu and PHP 5.2.3. They were run two million times benchmarking the different methods for:

• function calls
• __call
• __get
• __set
• iterators (array)
• inheritance
• composition

His results are listed at the end of the post.