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.

Though in the past they enjoyed both popularity and a certain amount of prestige, without a doubt Singletons have progressively become one of the most evil and despicable villains in object-oriented design. Singletons earned their bad reputation for a reason: bringing them to life requires the programmer to deal at least with a static method. This is simply an elegant masquerade for creating a global access point (which in most cases is mutable as well) throughout an entire application. And we all know that global, mutable access is unquestionably a bad thing that must be avoided at all costs.

In this first part (of two) of the series they introduce the Singleton pattern and show how, via an example of using a database adapter interface to work with a MySQL database, in a tightly coupled example. In the second part of the series, they'll show how to break these apart using dependency injection.

The ability for a class to inherit from multiple parents is maligned by many, but can be a good thing in some situations. For those working in PHP, multiple inheritance has never been an option; classes are limited to one parent, though they can implement many other datatypes through the use of interfaces. Interfaces can lead to code duplication in improperly-factored inheritance hierarchies. Even in well-architected hierarchies, multiple classes that implement similar methods can contain a lot of overlap.

He starts with a definition of what traits are and where their real usefulness is (as well as what should be the difference between a class and a trait). He gives an example of a typical hierarchy where two classes extend a parent but then they both need the same functionality. Code duplication's not a possibility and inheritance make run into exposure issues. Traits come to the rescue by dropping in just the feature you need when you need it. His example code shows adding some logging to a simple class via a "Logging" trait and a "Singleton trait" example.

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.

The problem with static members in PHP is the poor initialisation capabilities. The initial value of a static property can only be a literal or a named constant. [...] The same problem exists for non-static properties too, but the constructor is a dedicated place to initialize non-static properties. But since we don't have Java-like static constructors in PHP there is no place to do static property initialization. In a lot of cases people do it by putting the assignment statements after the body of the class, but this method is very ugly.

An alternate method he suggests is using a singleton to initialize and grab the value of a class value. He gives some sample code to show how it might be done, but warns that it might not be the right way to do things. It has "significant disadvantages" that could cause trouble down the road (for one, singletons make it difficult to unit test).

One of these patterns is the Singleton design pattern, which is based on the mathematical concept of a singleton (a set with a single element). [...] Sometimes the Singleton pattern can help complete important programming tasks, but only you can decide where and when it fits your needs. As a pointer, the Singleton pattern fits well when you manage a shared resource [...] because your application should have only a single instance in order to avoid conflicting requests for the same resource and to minimize performance issues.

He shows an example of how to implement it, first as a class template and then in actual use (complete with code ready to copy and paste). He also shows how you can use the singleton pattern to act as a frontend to other classes, making a sort of polymorphism simple. Thankfully, he also explains some of the risks in using this design pattern and that "less is more".

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.

In this PhpRiot Snippet I will show you how to create and use singleton classes. A singleton class is a class that can instantiated once only. While it may not come up frequently, it can be a useful technique when it simply doesn't make sense to have than one instance of a class.

He shows how, by following a few rules, you can make a sample class that will only create and pass back a new instance of itself if ones doesn't already exist. It's a simple concept, but it can come in quite handy in the right situations. Just be sure you use them wisely.

Much more important than performance is the fact that both static methods and singletons suffer from major drawbacks. When it comes to deciding between the two, you might forgo the benchmark comparison and choose the third-party candidate: dependency injection.

He mentions the "dark side" of both static methods and singletons and how dependency injection can help rid your code of both. Instead of focusing just on the benchmark numbers, DI helps you keep your code more well-structured and "smarter" by scoping things to where they need to be and making them easier to test.

n the past several months I've been working with a rather large application built with symfony. I noticed that symfony makes heavy use of the Singleton pattern (other frameworks, like Zend do that too); everywhere in the code [...] Notice the amount of code needed by the Singleton pattern. Except the [shown] method, all the code in the class makes sure you have only one instance at any time during the execution.

He shows how to replace the standard singleton logic with something more specific and decides to test the two methods, seeing which of them can handle the most requests per second. His sample code is included for both the scripts called and the test script run. In all instances, the static call won out over the singleton instance easily. Even when tested with the Facebook compiler, the results were still the same.