Sergey Zhuk has written up a post to his site that wonders if the factory method violates the open/closed principle, a part of the SOLID set of principles for software development.

Consider an application that provides some statistics reports. Reports are present in different formats: JSON for API, HTML for viewing in a browser and pdf for printing on the paper. It has StatisticsController that receives a required format from the request and returns a formatted report. The logic for choosing a formatting strategy is hidden behind the factory.

He works through a code example of using the factory pattern to create this functionality, generating the fomatter from behind the factory. He then talks about adding a new formatter for CSVs and the update to the factory that would come with it. It's this last change he's wondering about as the Open/Closed principle states that objects should be open for extension but not modification. While the answer is technically "yes" he explains that the purpose of the factory is to abstract the logic away so you only have to deal with one type of thing rather than making it yourself every time.

According to Open-Closed Principle the “correct” solution would be to create a new factory with the same interface. That said, adherence to this principle should always be weighed against other design principles like KISS and YAGNI.

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 response to a few other posts about the use of "final" in PHP development, Freek Lijten has posted some of his own thoughts and some of the things he came to realize about its use in his own development.

I read a blog by Brandon Savage a couple of weeks ago and it triggered some thoughts. He refers to a blog by Marco Pivetta which basically states "Final all the things!". Brandon comes back with a more mild opinion where he offers the notion that this approach might be overkill. Since both posts got me thinking I tried to organise my thoughts on this in the following post.

Freek talks about a pretty common trend in the PHP world: the very rare use of "final". He suggests that "extension" of classes is a bad idea (or at least should be used a lot less) and how he has seen it commonly misused. He then shares two reasons why he thinks "final" is a good idea, mostly centering around how easy it is and how the Open/Closed principle applies. In the end, he notes that he'll be trying to use more "final" in the future and see where it takes him and his code.

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.

On PHPMaster.com there's a new post continuing their look at the SOLID development methodologies with the "O" in the acronym - the Open/Closed Principle:

I have to admit the first time I peeked at the academic definition of the Open/Closed Principle, its predicate was surprisingly clear to me. Leaving all of the technical jargon out of the picture, of course, its dictate was pretty much the mantra that we’ve heard so many times before: "Don’t hack the core". Well, admittedly there’s a pinch of ambiguity since there are at least two common approaches to keeping the “core” neatly preserved while extending its functionality. The first one (and why I used deliberately the term “extending”) would be appealing to Inheritance. [...] The second approach is Composition.

He illustrates the effective application of the principle with the creation of a HTML rendering class. The first version is non-polymorphic and just renders the example DIV and P elements that are passed into it. He changes this up by shifting these element classes into something extending an AbstractHtmlElement class (sharing an interface between them) and updating the renderer to handle these correctly.