To help better explain each of the three aspects of DI I discussed in the previous article I'll be going over each more thoroughly and with those code examples requested. I'll be going through each point one at a time as the explanations will likely be of some length compared to the original post.

He starts with the "villain" of the story - the Singleton design pattern, a difficult to test method that lulls you into thinking you're not in the global scope. He talks about the problem of using this approach and how the Factory design pattern can be used to create an alternative. He changes up the example to create a "DbTableFactory" class that can be used to create the objects needed - in this case a "UserTable" object with the connection injected into it at construct time.

The Factory Method pattern is a design pattern used to define a runtime interface for creating an object. It's called a factory because it creates various types of objects without necessarily knowing what kind of object it creates or how to create it.

Code is included showing how to make creating "Product_*" classes as simple as calling a "build()" method with the type. A slightly more complex situation is also included - building factories inside of factory methods. For more about the Factory design pattern, check out its Wikipedia page (that includes some common uses and some pitfalls to watch out for).

This is just a short follow up to a recent tweet of mine. I have seen this repeatedly happen, even to top notch and usually very careful developers (*). I am not sure why this mistake happens so frequently, but quite often you see code that changes the parameter order for custom Exception constructors. I guess it's mostly because in these cases the developer wants to pass some magic parameters that contain the message (and potentially also the code).

He recommends that, if you really do need to change something like the order of the parameters, use something like a factory to handle the reorganization for you.

To be clear, I think Design Patterns have their place. When used properly, they can make our lives easier and our code better. When they're misused - "If the only tool you have is a hammer.." - then they can become the bane of our existence. Unfortunately, some Design Patterns seem more susceptible to this than others. So maybe this is less "design patterns I hate" and more of "design patterns that have been abused beyond all sense of reason"... I'll let you decide.

He has three of the most commonly misused design patterns in his list. Anyone who has looked into using patterns in their applications will recognize them:

• Active Record
• Factory
• Singleton

For each, he describes some of the bad implementations he's seen and notes that, while these are commonly abused, they can still be redeemed by being used appropriately.

In this article you will learn how to use the factory pattern design in your PHP application to construct different objects for interrogating a database (books) and displaying the records from a table (bookstore) [...] The essence of the factory method pattern is to "define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses."

He illustrates with a few sample scripts - one that displays a series of messages on factoried instances of a class, another that randomizes a display of images and another that handles book data and outputs the results.

A design pattern is a template used by software engineers as a guideline of how to solve a particular problem. [...] In this series of articles I plan to explore some of the design patterns that i have found most useful in my time as a PHP developer, providing examples and notes. So, this being the first, we'll take a look at the Factory Method Pattern.

He defines the pattern - an interface to a class without the caller having to know what type of class it is - and a code example showing an abstract class with a "Factory" method that pulls information from either a jpeg or png class based on the extension of the file name given.

Design patterns are optimized, reusable solutions to the programming problems that we encounter every day. A design pattern is not a class or a library that we can simply plug into our system; it's much more than that. It is a template that has to be implemented in the correct situation. It's not language-specific either. A good design pattern should be implementable in most - if not all - languages, depending on the capabilities of the language.

They introduce a few of the more widely used patterns including the strategy pattern, adapter pattern, factory methods, decorator and singleton patterns. Each comes with a bit of code showing how it would work and a "where would I use this?" section with a better example.

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.

[This series will] touch the majority of the known design patterns, with a special look at their application in a php context. A running code sample will be provided for each part of this series, along with the theory and the terminology of each pattern.

In the Abstract Factory (or just Factory) post he includes a diagram of the pattern's relationship with other "participants" and has a Zend Framework-based code sample to create a simple WidgetHelper. In the second article he looks at the Builder pattern and how it can make creating instances of complex objects a bit easier. As before a diagram and code are included.

You can keep up with the rest of the posts in the series as they're added by following along here.

In the last post, I introduced Dependency Injection and show useful cases where it allows classes decouplng. I also wrote about the problem of how to inject a service in a class that has to be instantiated not application wide but in the business logic.

He creates an example that shows a not-so-good place to use dependency injection and offers a solution - a factory that creates the objects as they're needed instead of having them floating around when they're not needed. He also talks about the difference between two types of business objects to consider in dependency injection: entities and services (hint: one depends on the other).