Using the Singleton Principle Part 2; Ignoring Part 1

I suppose it could be argued that the same problem plagues all design patterns; when they are applied incorrectly they begin to inhibit your software more than they enhance it. The Singleton pattern, even though I previously thought it was THE creational pattern to use in every case, is not the only design you should rely on when developing software. In fact, there may not really be very many cases where its usefulness outweighs its disadvantages.

Let's say you have a piece of software that uses AJAX to let a user interact with your software, whatever your software might do. You have a Singleton session, Singleton user, and Singletons for your internal state data and functions. Then your software really takes off, like we hope happens to us, and you find out that you really should have an option for 2 users to interact with your software in the same session. But, the user class is a singleton and only allows one instance. You can modify the Singleton get_instance() function to take a parameter, user ID, and return the correct instance. Changing your Singleton user class is easy. Modifying all 300 calls to user::get_instance() is going to be a long and annoying process. You invest all your time anyway and the software runs well for a while until you realize that your software would be more useful if it supported an unlimited number of users in a session.

Conceptually, you left the realm of Singleton last time you modified the user class and you entered the realm of "Multiton." But what is a "Multiton" anyway? The class would have to allow unlimited copies with different state data. This is the entire concept behind having instances. So now, your user::get_instance($userID)->function_name() looks really silly compared to $instance->function_name(). Essentially, you've created a gigantic waste of processor time and typing time because you're adhering to a design principal that doesn't fit the scenario.

Since Singleton is a future expansion killer, what else can be used? That depends on any state data the class holds. If there is no state data, for example in a system class that holds properties that rarely, if ever, change. This class could become entirely static. You'll lose some magic methods from PHP, but for a class only having static methods and properties, the losses are trivial. If the class has state data, make it a regular class. If there has to be a handle to the class instances, make a manager class to hold the instances and either pass the manager by reference to the constructor of the instance or make the manager a Singleton. Having multiple managers doesn't make sense because you're only dealing with a request from one user's browser at a time. The request may involve multiple user instances, but there won't be multiple requests with multiple user instances handled by the same PHP process.

Let's hope there's no "Part III" to this article, because that would not be good.

~Garrett