Gonzalo Ayuso came across a situation where he needed to create a factory method inside of multiple classes but didn't want to have to create them each time. With class inheritance there had to be another way.

I have built a backend library. I have a tree of classes and i want to use singleton and factory patterns to my class set. Easy isn't it? [...] Now imagine you have a lot of classes. You must create over and over the factory function in every classes.

An abstract class is a perfect fit for this sort of thing, but there's not a good way to return the correct kind of object back from the factory method. That is, until you do some magic with a PHP installation version 5.3 and higher. With the get_called_class function, you can easily figure out where the request came from and return a correct object instance with one line.

Giorgio Sironi has recently posted a look at one of the more popular design patterns - the Repository pattern. He talks about how it can be used for two things: to create a collection of objects and the reuse of queries and their results.

A common infrastructure problem of an object-oriented application is how to deal with persistence and retrieval of objects. The most common way to obtain references to entities (for example, instances of the User, Group and Post class of a domain) is through navigation from another entity. [...] A Repository implementation provides the illusion of having an in-memory collection available, where all the objects of a certain class are kept

He gives an example of a method that grabs user information and encapsulate the database access for it so that it's not required to hit it for every run through their unit tests. He shows how to set up the interface for a GroupRepository and how to implement it in the test.

Keith Casey has posted a review of the php|architect book "PHP Design Patterns" by Jason Sweat to his blog today.

Diving into the book itself, Jason covers 16 Design Patterns. He covers the basic ones like the dreaded and horribly abused and misused Singleton to the more advanced Active Record and Table Data Gateway. While he covers all of them to a good depth, there are a number that deserve special mention.

These "mentionables" include the Strategy, Observer and Mock Object patterns - all three Jason covers well with some good examples included. Overall, he found the book good, but needing some work in some areas (like in updated code samples).

Matthew Turland has pointed out a pattern he's seen happening over and over again in the Zend Framework, what he calls the "Configuration Pattern".

Here's how it works. Have a look at the constructor for Zend_Form. It accepts an $options parameter, which can be an associative array or Zend_Config instance. If it's an array, setOptions() is called. If it's a Zend_Config instance, setConfig() is called, which then converts the Zend_Config instance to an associative array and passes that to setOptions(). So, either way, you end up in the same method with the same type of data. setOptions() then iterates over the associative array it receives. It takes the index of each element and looks for a corresponding setter method.

This method helps to reduce the overall function calls (including a method_exists) and can help to produce cleaner code in the process. A comment on the post also points out related comments from Matthew Weier O'Phinney about these options.

Following up on a previous post of his concerning a bit of different thinking around models in Zend Framework applications, Jim Plush is back with this new post about some decisions he's made.

As a follow up to my previous post I'm going to post some live examples of model layer with Zend framework based on Domain Driven Design concepts. I've spent the past few days studying up on domain driven design as well as a lot of Martin Fowler's work in relation to domain modeling and I think I have at least some code to start with that could get some conversations rolling.

Because of the lack of a standardized model layer in the Zend Framework, multiple methods for creating and using them are possible. Jim has created some examples with the Domain pattern to make a basic User class. His example shows how to create a User instance and run several methods on it (like getNickname, setNickname) and how you could pass it into an example web service as a complete object.

The PHPClasses.org blog has posted a new book review of the APress book "Pro PHP: Patterns, Frameworks, Testing and More" (Kevin McArthur).

If you really want to improve your PHP skills to be at the enterprise level, you must read this book. Despite there are several other PHP books about OOP, I have never seen a book that addresses the subject so deeply and, at the same time, keeping it simple.

The reviewer looks at what the book covers - PHP6, documentation, Phing, SPL and much more. Check out the full review for more on what the reviewer thought.

Tobias Schlitt has written up a new post looking at the identity pattern (an Enterprise application design pattern) and an implementation of Identity Map in the eZ Components framework.

The pattern affects the data access layer of an application and helps to avoid inconsistencies in data objects of your application. [...] In this article I want to give you a rough overview on the pattern itself and show you how you can test and use the functionality of PersistentObject.

The identity map pattern allows you to store/fetch objects across execution instances to reduce the overhead of recreating those objects every time. Tobias shows off the PersistentObject component as an example of it in action. It can create an identity map and store values (like session information in their example) and even includes methods to grab related objects as defined by calls to addRelatedObject.

On the Content with Style blog there's a new post by Pascal Opitz talking about a suggested caching pattern for use with the Zend_Cache component of the Zend Framework and the __call magic method.

The initial thought behind this is that a model should be able to return calls either uncached or cached, without initializing some cache object every time. It should be easy to switch between the two calls, and the cache should be coming with the model object already.

He compares the old way - making a new cache object and performing actions based on that - to his new way of already having a cache object as a part of the model to help with storing any information you wanted anywhere inside. He includes a code example showing the method, basically a call to create the cached object in the constructor and, when a method is called, the __call traps it and dynamically attaches that cache object to it.

DevShed.com has posted the seventh article in their series looking at the Active Record design pattern in PHP applications. In this latest tutorial they show how to replace the older MySQL client libraries and use the newer mysqli client instead.

Well, as you'll surely recall, I built this class by using the old MySQL library included with the PHP distribution, which is good and efficient. But it's worth making the effort to see how this sample class can be rewritten by using the newer, revamped "mysqli" extension. Thus, this last episode will be dedicated exclusively to doing this, so you can have at your disposal an enhanced versions of the class.

For most of the code, you won't see too much of a change - the methods are named similarly and the results are references differently, but you shouldn't have to make too much of a change.

Matthew Weier O'Phinney has another post in his look at the decorator pattern in Zend Framework applications. This time he takes a step back and shows how to execute them individually.

In the previous installment of this series on Zend_Form decorators, I looked at how you can combine decorators to create complex output. In that write-up, I noted that while you have a ton of flexibility with this approach, it also adds some complexity and overhead. In this article, I will show you how to render decorators individually in order to create custom markup for your form and/or individual elements.

So, instead of registering them with the Zend_Form element, he shows how you can pull out the one decorator (with a getDecorator call) and render it separately. It can be simplified even more with the renderSimpleInput method called on the decorator object. He gives a use case example in defining a form that needs more exact control over the layout.