The StarTutorial.com site has continued their introductory look at design patterns and using them in PHP with a new article covering the Singleton pattern.

[The Singleton pattern] ensures a class has only one instance, and provides a global point of access of it.

They use a more real-world example to illustrate the use of a singleton: organizing patients at a doctor's office using a ticketing system. In their example, the system makes use of a "TickerPrinter" object to represent the ticketing system. The issue is that the printer has to check every time to see if it needs more paper or if the ink is out in the first example. They refactor this to use a singleton, creating a getInstance method to return the same instance of a "TicketPrinter" object each time it's called rather than having to create a new one and manage it individually.

The QaFoo.com blog has a new post sharing a helpful hint on refactoring singletons to make them more testable. Singletons and notoriously difficult to test due to how it can potentially return an unexpected version of an object.

So your code base is littered with singletons and using them? Don't worry, you can start refactoring them out of your code base class by class and introduce increased testability at every step. This strategy is very simple to implement and the probability of breaking your code is very low, especially when you are becoming more experienced with this technique.

They give an example of a service class that uses a singleton to get an instance of the Solarium_Client class via a static method call. They show how to refactor this out into a separate method and then use the "lazy initialization" pattern to only use the singleton if the property isn't already defined. This then allows you to use a setter to inject your own client during testing (a mock most likely).

On the QaFoo blog today Kore Nordmann has posted a suggestion that could make your unit testing life simpler: get rid of statics (variables, methods, etc).

When people start (unit-)testing their code one of the worst problems to tackle are static calls. How can we refactor static calls out of an existing application without breaking the code and while producing new features? How can we get rid of this big test impediment?

They illustrate the main problem with a simple UserService class that contains a static function which, in turn, uses static calls to a Cache and a DB class. The major issue is that, when the static getUser method is called there's not a way to mock the Cache or DB classes, resulting in the actual handlers being called. They offer three things you can do to help refactor away from using static methods:

1. Replaceable Singletons
2. Service Locator
3. Dependency Injection

For each item on the list a brief explanation is provided of what it is and how it helps you get away from the singletons scattered throughout your codebase (and how it makes things easier to test).

In a recent post to his site Tim Cotten talks about how it's possible to screw up singletons in PHP. Singletons are a design pattern that returns the same object once it is created each time the method is called.

“Echo chambers” are an oft-encountered downfall of developers when learning new skills or implementing unfamiliar systems. What begins as a simple question leads to a collection of up-voted knowledge perfectly ready to be copied into your project?—?a great thing for productivity (if you don’t mind getting it wrong).

[...] With that example of echo chambers in mind let’s follow the path of a developer deciding to implement the Singleton pattern in PHP.

He goes through the mindset of a PHP developer wanting to use a singleton in their application, finding an example on the web for their need (making a PDO instance). He gives a sample implementation based on the web examples and tries to execute a test script....with a less than helpful error message. He points out that he's not picking on the source of the example itself, but using it as an example of the "echo chamber" idea perpetuating an example without understanding the logic.

He continues along this same path of thinking with an example from another source - StackOverflow. He cites a specific example, points out the issue and the code it contains. He ends the post with some helpful suggestions on how to "break" this echo chamber and improve the resources in various places on the web.

On the NetTuts.com site today they've posted another in their series introducing the various design patterns that have been established in software development. In this new post they talk about the Singleton pattern (or "anti-pattern" as it's sometimes called).

In this article you are going to learn how to implement the Singleton design pattern, and why and when to use this pattern in your application. As the name "Singleton" suggests, this method allows us to create one and only one object of a class.

They start with a basic definition of the pattern that, at its heart, is about reusing one and only one instance of an object. To help make it more concrete, they include an example that's refactored to use the Singleton pattern: creating and reusing single instances of database connections (PDO). The article also talks a bit about the idea of the Singleton being an anti-pattern and how it can make things like unit testing difficult.

For those that might be new to development, the concept of "design patterns" could be one you're just approaching. These common practices define some "patterns" of development that have been proven to provide good structure and maintainability to applications...when applied correctly. PHPBuilder.com has an introductory article showing you how to use five of the most common patterns: Factory, Singleton, Observer, Chain of Command and Strategy.

Design patterns provide a generic reusable solution to common problems. A design pattern is not a concrete solution that can be converted in to source code or a machine code rather it is a template which can be used to solve a problem in different situations. Design patterns help in faster development as the templates are proven and from the developer's point, only implementation is required. Design patterns not only make software development faster but also encapsulate big ideas in a simpler way.

For each of the patterns represented a brief description is included and some sample code is given showing it in use. There's not too much depth in this post, so if you're looking for more "meat" on these patterns, I'd suggest checking out some more advanced articles on SitePoint.com.

Allan MacGregor has posted his latest in his look at design patterns in PHP with this most recent post about the Singleton pattern.

The singleton pattern is used to restrict the instantiation of a class to a single object, which can be useful when only one object is required across the system. Singletons are designed to ensure there is a single (hence the name singleton) class instance and that is global point of access for it, along with this single instance we have global access and lazy initialization.

He provides a basic Singleton implementation in PHP, a "User" class that always returns the same instance of itself no matter how many times the "singleton" method is called. He continues on and touches on one of the pain points around singleton use - many developers consider them an anti-pattern because their results can make it difficult to correctly test. He talks about how they break the Single Responsibility Principle (part of SOLID) and how they can hide dependency injection.

Singletons, Anti-patterns, and patterns in general are not good or bad; what makes a Singleton an Anti-pattern is not the pattern itself but how often is poorly implemented and how easy it is to do so.

Russell Walker has a post on his site sharing some suggestions about effectively dealing with global data in your PHP applications.

Almost every web application needs to handle global data. There are certain things that just have to be available throughout the entire code base, such as database connections, configuration settings, and error handling routines. As a PHP developer, you may have heard the mantra 'globals are evil', but this naturally begs the question 'what should I use instead of global variables?'

He includes four different options (five including the actual use of global variables):

• Static classes
• Singleton
• Registry
• Dependency injection

For each of the options he includes summaries of both the advantages and disadvantages as well as some sample code showing their use. Ultimately, he points out that it's up to the developer of the application which option fits best.

On the Codeception site they've posted a guide to using the AspectMock feature of the testing tool to prove that "nothing is untestable."

We already announced AspectMock, the mocking framework that may dramatically change the way you do testing in PHP. In this video Jeffrey Way shows how AspectMock is different from others. In this post we will demonstrate its powers too, and we will try to break some stereotypes about PHP testing. To get the code tested, you should always keep in mind how you would write a test for it. We know unit testing requires some good practices to follow and bad practices to avoid.

Their first example involves testing singletons, notorious for being difficult to test because of their "global" state. He also gives a more practical example using a Yii2-based application and a login form. True to its name, the AspectMock uses Aspect Oriented Programming concepts to make the "magic" happen behind the scenes.

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.