On the Zumba Engineering blog today Chris Taylor has a new post about mocking in PHPUnit, specifically how to handle those pesky Singleton methods lurking around your codebase.

In many of our projects, utilities and vendor classes are implemented with a singleton pattern. [...] In this post, we'll cover a nice way to inject a PHPUnit mock object for use in testing methods that utilize singleton classes.

He starts by introducing mocking and how to use mock classes in PHPUnit with a simple "sayHello" example. Adding on another layer, he creates a "SomeclassMock" class, defining its own "expects" and "cleanup" methods. This class forces the Singleton method to act more like a regular non-static method and "resets" it after each use.

Gonzalo Ayuso has a new post that responds to the idea that "singletons are a problem when testing" your applications with something like PHPUnit.

Maybe this pattern is not as useful as it is in J2EE world. With PHP everything dies within each request, so we cannot persist our instances between requests (without any persistent mechanism such as databases, memcached or external servers). But at least in PHP we can share the same instance, with this pattern, in our script.

He illustrates a bad side effect of this sharing of resources with a simple unit test that increments a counter in a class. He notes that, because the script shares the object, you can't reliably know the state of it as you don't know what's happened before your use. He recommends two things to help the situation - either not use them at all or destroy the instance each time after using it (counterproductive to using a Singleton, obviously).

PHPEasy.co.uk has a new tutorial posted introducing one of the most common (and often misused) design patterns out there - the Singleton pattern.

In this first tutorial in the design pattern series we are going to investigate and implement the singleton design pattern. [...] A design pattern is a common solution to a given problem, problems in programming tend to recur and we often find ourselves trying to solve the same issues over and over. The common techniques that provide solutions to these problems can be referred to as design patterns.

He talks about some of the most common uses for the Singleton pattern (mainly replacing a global variable) and includes an example of using one to fetch a database object.

Following his recent allegory about the Factory pattern (as described in story form) Greg Bulmash has posted the Legend of the Singleton to help with your understanding this pattern.

The Singleton pattern provides an interface to let your application always pull out the same object (or make a new one if it needs to).

His legend talks about kings, mythological data sources and the overloading of multiple "hoses" (connections) to it. Also included is a code example showing a simple database class that includes a "getInstance" method acting as the Singleton to return either a new or the (same) current instance.

In response to some of the comments made on his previous post about why you should use dependency injection in your applications, Charles Sprayberry is back with some more concrete examples showing how it all works with some code to back it up.

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.

On DevArticles.com today there's a new tutorial posted talking about one of the more popular design patterns, the Singleton, and how it can be implemented in PHP.

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.

Ryan Gantt has a new tutorial posted to his blog today looking at one of the features in the upcoming PHP 5.4.x releases - traits. Specifically he looks at the horizontal reusabillity they allow for in your applications.

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.

On the Zend Developer Zone today there's a new post from Keith Casey about some of the design patterns he hates - ones that are misused too often and have become more of a "worst practice" at times than others.

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 new post to his blog Bence Eros shares some of the frustrations and issues he's had when dealing with static methods and properties in his applications and how, with a bit of re-engineering, you might be able to have "life without static".

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).

If you haven't taken much of a look at design patterns and how they can help your development life, the Singleton pattern is a good place to start. On PHPBuilder.com there's a new tutorial introducing this handy pattern and how it might fit your needs.

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".