Paul Jones has posted his thoughts about factory behavior in PHP applications (well, really any kind of application as it's a pan-language concept). He suggests that factories should only create the objects requested and not persist them.

In a recent Reddit conversation, some of us went off on a tangent about factories. I maintained then, and do now, that a “factory” always-and-only returns a new instance. If you have a “factory” that returns anything other than a new instance, it’s not a factory alone. In the case of factory methods, it is a factory + accessor; in the case of factory objects, it is a factory + registry. A “factory” (whether a factory method or factory object) is one way to separate object creation from object use.

He gives an example of a case where an object needs to be created for a "doSomething" method. His first example shows the creation of the "Item" inline, mixing the creation and use of the object into the same place. He replaces this with a "factory" class/method that only returns the new "Item" requested. He points out that a factory method that retains the object (like as a class property) has the same problem as the first example - retention. Instead he suggests an intermediate "collaborator" that splits out the creation and retention once again.

On DZone.com Giorgio Sironi has a new tutorial looking at the Factory design pattern, specifically the use of a "collaborators map" to create them inside of a dependency injection container.

Like for every library, you should first evaluate if the costs and benefit of integrating [a dependency injection container] are worth it. The alternative is to write your own factory classes, methods and closures: this article explains one of the patterns for building dynamic Factory objects, and as such lowers the cost of the second option. What you know how to do has a lower cost than what you still have to learn, considering risk and implementation time.

He talks about the "old way" of making your own factories to create objects and how the collaborators mapping can replace that. The collaboration mapping is passed in when the object is created and a "create" method is called when the objects (or sub-objects) are needed. He also mentions some of the "easy" and "hard" changes you could make to this setup to expand its functionality.

Following the release of the phpspec SpecBDD tool, Konstantin Kudryashov has posted this new article talking about SUSes ("Subject Under Specification") and how they relate to the functionality phpspec offers.

First of all, phpspec2 is not a testing framework. It's a SpecBDD tool. It means, testing is not our primary aim. Tool's job is to enforce and make SpecBDD in project flawless and phpspec2 uses all available methods to do that - state of the artformatters, class and method generators and lot of othe fancy buzzwords :) Today, i want to explain you the heart of phpspec2 - SUS, collaborators and prophets.

He starts off defining specifications as a list of behaviors about how an object should behave and the abilities that come with them (like "getTitle"). He shows assertions, like "shouldReturn", and how you can use Collaborators to evaluate the interfaces between objects.