In a new post to his site Frederick Vanbrabant tackles the integration operation segregation principle. While the term sounds intimidating, it's just a long way to say something you probably already do: refactor code into smaller testable chunks.

A few weeks ago I attended a DDDBelgium meetup where I was lucky to participate in a refactor workshop lead by Pim and Joop. After the incredible workshop Pim, Dries and me were discussing some code that we refactored earlier . Not so long in the conversation the words “Integration Operation Segregation Principle” casually got dropped by Pim.

Now I’m going, to be honest with you (as I was with them), I had no idea what the hell he was talking about. And maybe neither do you.

He starts with some simple code for a "calculator" class with a calculate method to handle the pricing of a rental car. He includes the test for the class/method as well, using a mock object and several expects calls to handle the method calls. The test ends up being larger than is probably good, so he looks into refactoring the original code to abstract out some of the functionality and make it more testable. In the process this also makes the code easier to follow and, while there is more of it, more maintainable and flexible in the end.

On the Web-Techno.net site there's a new tutorial posted that talks about the DRY principle in development (Don't Repeat Yourself) and why you might be misunderstanding the intent.

I know what you are thinking: "Again a boring article on DRY? Don't we have enough already?". You might be right. However I see too many developers (junior or senior) applying DRY like they are doing some witch hunting. Totally randomly or everywhere they can. So apparently we never have enough DRY principle articles on Internet.

A little reminder for those in the back who don't follow: the DRY principle means "Don't Repeat Yourself" and was first introduced in the The Pragmatic Programmer. The principle itself was known and applied before this book came to life. However the Pragmatic Programmer defined it precisely and put a name on it.

He starts by defining the original intent of the principle: not repeating knowledge (not necessarily repeating code). He gives an example of a e-commerce site and the logic around "shipments". If there's logic around these shipments happening in multiple places in the application, that can lead to maintenance issues down the line. He suggests creating a single instance of the knowledge about shipment handling rather than just reducing code duplication. He gives an example of a product instance and code duplication happening in some of the data validation. After showing a possible solution for this particular issue he gets into some issues that come from over-DRYing your code including useless abstractions and premature optimization.

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.

The TutsPlus.com site has posted the next tutorial in their "Object-Oriented Autoloading in WordPress" series - part two - expanding on the basics presented in the previous part of the series.

In the previous tutorial, we covered a handful of concepts, all of which are going to be necessary to fully understand what we're doing in this tutorial. Specifically, we covered the following topics: object-oriented interfaces, the single responsibility principle, how these look in PHP [and] where we're headed with our plugin.

[...] Ultimately, we won't be writing much code in this tutorial, but we'll be writing some. It is, however, a practical tutorial in that we're performing object-oriented analysis and design. This is a necessary phase for many large-scale projects (and something that should happen for small-scale projects).

First they briefly cover the environment you'll need to follow along (already set up if you followed along with part one). They then get back into the code, evaluating the current state of the custom autoloader and investigating how it can be broken down into a class and a set of methods instead of procedural code. They work through the different functional parts of the autoloader and how to break it down into classes with only one job (the "single responsibility principle"). They end up with the autoloader that uses NamespaceValidator, FileInvestigator and FileRegistry instances to get the job done.

The TutsPlus.com site has posted the next part of their series looking at autoloading in WordPress plugins. In this latest post the most from just the namespacing and setup into the actual code - creating some simple object-oriented classes that can be easily autoloaded.

I recently wrapped up a series in which I covered namespaces and autoloading in WordPress. If you're not familiar with either of the above terms, then I recommend checking out the series. [...] While working on the series, specifically that of the autoloader, I couldn't help but recognize a number of code smells that were being introduced as I was sharing the code with you.

This isn't to say the autoloader is bad or that it doesn't work. If you've downloaded the plugin, run it, or followed along and written your own autoloader, then you know that it does in fact work. But in a series that focuses on namespaces—something that's part and parcel of object-oriented programming—I couldn't help but feel uncomfortable leaving the autoloader in its final state at the end of the series.

They move away from just autoloading and namespacing quickly and move into OOP concepts like interfaces, implementing them, the "single-responsibility principle" and a few other helpful principles. They define the goals for the work ahead and move into the code, updating the current state of the plugin to use these new ideas.

Jason McCreary has written up a post covering a popular topic from the eXtreme programming world, a talk he presented on the subject and a bit of his own personal experiences with it: YAGNI or "You Aren’t Gonna Need It".

Last week I spoke at Laracon US 2016 about Practicing YAGNI. First, let me say it was an honor to present for such a large audience at such a premiere conference. I received a lot of feedback and interest in my talk. To that point, many people have asked me to share my slides. As the slides were mostly placeholders for discussion, I felt a blog post would better summarize the talk.

[...] YAGNI is a principle of eXtreme Programming - something I practice daily at work. YAGNI is an acronym for You Aren’t Gonna Need It. It states a programmer should not add functionality until deemed necessary. In theory, this seems straightforward, but few programmers practice it.

He talks about practicing YAGNI and why it's hard for the average developer. He starts with the overall problem it solves and the more relatable KISS (Keep it simple, stupid) and MVP (minimum viable product) realms of thought. He then gets into some of the ways that you can practice YAGNI in your own development, mostly dealing with the timing of feature development rather than complexity. He also includes some times when it doesn't make sense to practice YAGNI and, finally, what practicing it means to him personally.

In this new post to his site Mathias Verraes approaches the concept of the DRY principle (Don't Repeat Yourself) as being more about knowledge. He includes two "real world" examples where the business rules can change around you.

“Don’t Repeat Yourself” was never about code. It’s about knowledge. It’s about cohesion. If two pieces of code represent the exact same knowledge, they will always change together. Having to change them both is risky: you might forget one of them. On the other hand, if two identical pieces of code represent different knowledge, they will change independently. De-duplicating them introduces risk, because changing the knowledge for one object, might accidentally change it for the other object.

In his examples, he shows how hard-coded rules (like "a product container can only contain 3 products") could just be around certain needs, not the entire range of requests. He covers some of the principles of Domain-Driven Design and how they apply here, pointing out that changing rules in one part of the application can have an effect on other parts depending on it.

In his latest post Wojciech Sznapka reminds us that type hinting is important in your PHP applications and can help provide more structure and better overall code practices.

One of my favorite PHP interview questions, is: what is Type Hinting and why it’s important? Putting definition in one sentence, Type Hinting is a way to define type of parameter in function signature and it’s a sine qua non to leverage polymorphism. [...] So given the fact, that Type Hinting is optional and we don’t need to specify types of parameters passed to the method – why bother? Answer is easy: well prepared method signatures defines your model and are part of the “contract” that your code reveals to its consumers. It also prevents many silly errors and keeps codebase clean and coherent.

He talks about the best practices on using type hinting including where to put them (in an interface or base class or child class?) and some of the pros and cons of each. He also points out that some practices around type hinting, like overriding the hint and calling the method with unexpected/variable input, should be avoided (see the L in SOLID).

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.