In a new post to his site Tomas Votruba comes back to a topic he posted about previously - the collector pattern - and provides a simpler, more introductory look at the pattern and what it's useful for.

I wrote Why is Collector Pattern so Awesome a while ago, but I got feeling and feedback that it's way too complicated.

The pattern itself is simple but put in framework context, it might be too confusing to understand. That's why we look on collector pattern in minimalistic plain PHP way today.

He uses a calculator example help explain the use of the pattern, starting with a simple class that calculates the price of a product + VAT. He then shows a few examples of how it could grow over time as business requirements change. He refactors the class to make it easier to add in these one-off changes by setting them all as "calculators' in a calculator collection. He provides the code examples for this refactor and an example of it in use.

In a new post to his site Tomas Votruba shares some of his thoughts about why he thinks the Collector pattern is so awesome. The Collector pattern is one of many design patterns that can be used to create well-structured applications.

I already wrote about Collector pattern as one we can learn from Symfony or Laravel. But they're so useful and underused I have need to write a more about them.

Yesterday I worked on Rector and needed an entry point to add one or more Rectors by user.

He then goes through the process he followed during the refactor and some of the questions he asked:

• Add a Provider?
• Use Expression Language?
• Does Collector Scale?
• Add Tagging?

He finishes the post with one last thought about git history and how it should "tell the story" of the refactoring.

Marc Aube has a new post to his site that introduces you to the specification design pattern, a technique that's useful for ensuing the current state of an object is valid.

The specification pattern is a software design pattern used to codify business rules that state something about an object. These simple predicates determine if an object's state satisfies a certain business criteria. They can then be combined to form composite specifications using logical operators. Use a specification to encapsulate a business rule which does not belong inside entities or value objects, but is applied to them.

He suggests a few things the pattern could be useful for like validating the current state or define how an object should be created. He gives a few more "real world" examples and then gets into the code to create a custom specification. In his "CustomerIsPremium" spec he defines a single method on an interface to determine if the Customer given is correct. He then creates a class instance and encapsulates the logic inside its "isSatisfiedBy" method. He also includes a bit more complex example, showing how to create a composite specification for handling grouping like "and", "or" and "not" assertions. Finally he looks at how to build specifications that can be passed in and used as selection criteria. He does point out that this can leak database handling into the specification layer, however, and should really be avoided without a inversion of control method in place.

NetTuts.com continues their series covering the basics of design patterns (in PHP) with a new article about the Command design pattern. This pattern is particularly useful for executing self-contained "commands" without other interaction.

In this article, we will be going through the command design pattern. As the name says, in this pattern we will be dealing with executing various commands. [...] Basically a pattern has numerous elements involved, which are as below. In the next section, we will be exploring each element with a code example. I will be taking the example of radio actions—very basic actions would be turning the radio on or off. So let's dive into each element.

Using the illustration of the radio, they go through the creation of the classes for the controls (on/off) and the two matching commands. The invoker is then told to execute the "turn off" command on the radio control object passed in. This sounds a little confusing but the code included in the article makes it clear how this implementation of the command is structured.

In the latest post in their series looking at common programming design patterns, NetTuts.com talks about the Adapter pattern. This pattern makes it easier to swap out different connection types via an abstracted interface.

In this article, we will continue our discussion on design patterns by taking a look at the adapter design pattern. This particular pattern can be used when your code is dependent on some external API, or any other class that is prone to change frequently. This pattern falls under the category of "structural patterns" because it teaches us how our code and our classes should be structured in order to manage and/or extend them easily.

He starts off with the problem he's aiming to solve: a change in a "Twitter" class from one method name to another. An "adapter" lets an existing class be used from another interface, requiring no to minimal changes to the original class. He refactors the example to use an example of an adapter, creating a class that defines an object that passes in the original "Twitter" class instance and wraps the "send" call in its own method. With this in place, he also shows how to create a brand new adapter for Facebook, mimicking the "send" method, just with different functionality.

On PHPBuilder.com today they have a new post showing different configuration patterns for getting localized settings into your applications. They show the use of INI files, PHP scripts, text files, XML data and a database call.

PHP is a cross platform language. It is a server based application so we must think about the configuration settings of the PHP software. There are various ways of creating configurable PHP applications. The configuration flexibility comes as a built in feature in PHP. But we must understand the requirement clearly before making an application configurable. This article explores different PHP configuration patterns and their implementation.

For each of the options mentioned, there's a brief description of what the method is, some of the common uses and a code example showing a basic implementation. The database pattern is the only one without a code example as the database interface varies widely from application to application.

Allan MacGregor has posted his latest in his look at design patterns in PHP with this most recent post about the Singleton pattern.

The singleton pattern is used to restrict the instantiation of a class to a single object, which can be useful when only one object is required across the system. Singletons are designed to ensure there is a single (hence the name singleton) class instance and that is global point of access for it, along with this single instance we have global access and lazy initialization.

He provides a basic Singleton implementation in PHP, a "User" class that always returns the same instance of itself no matter how many times the "singleton" method is called. He continues on and touches on one of the pain points around singleton use - many developers consider them an anti-pattern because their results can make it difficult to correctly test. He talks about how they break the Single Responsibility Principle (part of SOLID) and how they can hide dependency injection.

Singletons, Anti-patterns, and patterns in general are not good or bad; what makes a Singleton an Anti-pattern is not the pattern itself but how often is poorly implemented and how easy it is to do so.

Allan MacGregor has a recent post to his site looking at another design pattern (previously he discussed dependency injection), this time it's the use of factories.

The factory pattern is one of the most commonly used Design Patterns, it is useful when we need to choose between several interchangeable classes at runtime. By using factories we are also separating the creation of an object from the actual implementation. We can define a factory as a simple design pattern that give us a convenient way to instantiate objects. A factory is capable of creating different types of objects without necessarily knowing what type of object is actually being created.

He talks some about the problems that factories try to solve and some of the common implementations - simple, abstract and the factory method. He also covers some times when it's useful to use the pattern (including the creation of complex objects). The rest of the post includes sample code showing the creation of a Product class, creating them manually and the refactor over to a factory created method, making it more flexible for products in the future.

On the PHP-Tip-a-Day site there's a new post from Greg Bulmash with an allegory about the Factory pattern (design pattern) to relate it to something a bit more practical and introduce some of its core concepts.

If you've read the About This Site page, you'll know that instead of pursuing my passion for computers, I got sidetracked into the arts in college. So when it came time for me to learn and explain the Factory Pattern, I thought it might be fun to express it as an allegory...

His example involves cars, axles and wood to illustrate how the Factory pattern lets you generate objects of different types automatically without having to worry about how they're created. He includes a code example in the form of an interface and a class that implements it (the "Axle" class).

On PHPMaster.com today they have a new tutorial focusing on using the Repository (a part of the domain driven design architecture) to enhance your model's current functionality.

Unlike mappers, though, which are part of the infrastructure, a repository characterizes itself as speaking the model’s language, as it’s intimately bound to it. And because of its implicit dependency on the mappers, it preserves the persistence ignorance as well, therefore providing a higher level of data abstraction, much closer to the domain objects.

Included in the tutorial is the full code you'll need to create a simple UserInterface class and a User model that extends it. He also makes a UserCollection class to handle working with multiple User objects and a UserMapper to handle the actual data source fetching. Finally, he implements the Repository on top of this base structure showing how it lays on top of everything via the UserMapperInterface instance. At the end some example code showing it in use is also included - making the PDO connection, creating the UserRepository and fetching by a few different data types (email, name and role).