The StarTutorial.com site has posted the next in their "Understanding Design Patterns" series of tutorials today. In this latest post they cover the Factory design pattern.

[The Factory design pattern provides] an interface for creating families of related or dependent objects without specifying their concrete classes.

They use the same fictional business as in the previous articles to put the pattern in a more "real world" situation. The goal is to create several "toy factories" that can build "toy" objects based on certain requirements: either cars or helicopters. The post starts with the creation of an abstract factory class and shows the concrete implementations of one for each type of toy. These concrete classes include basic properties about the toy and functionality to build out the basics (ex: a car has four wheels, a helicopter has rotors).

In this new post to his site Brandon Savage looks at the "myth of the untestable controller" and gives some tips to help resolve it.

It’s a persistent statement: controllers should have as little code as possible because they’re difficult, nay impossible, to test. Developers should force most of their code into the models instead, where business, validation and other logic can take place. [...] But this is not true. Controllers are no more or less testable than any other kind of code. What’s more, the fact that people believe controllers are largely untestable is an excuse for writing untestable code, not a valid design decision.

He talks briefly about where the myth might have come from (Zend Framework v1, with it's difficult to test controllers) and a note that, really, controllers are as testable as you want them to be. He give three things that could help make them easier to test:

• Using dependency injection/inversion methods
• Refactoring to use the Abstract Factory design pattern
• Using anonymous functions/closures over plain configuration settings