Software Design - The Singleton Pattern

The last of the creation patterns we will cover is the Singleton.  This is a pattern that has a little controversy around it and may even be an anti-pattern.  It is easy to implement, but the reason for needing one can trip you up. The Singleton Pattern Defined It helps to start with the "Gang of Four" definition and then we will dig into that. "Ensure a class only has one instance, and provide a global point of access to it." This is what we use when we need one and only one instance.  An example might be the application settings or an instance that represents a real-world device (keyboard, mouse, maybe even a printer or hard drive).  When we access values on an instance, they will be the same no matter which "instance" we utilize, and any changes will impact all code that uses it.  The good and bad properties of a Singleton is that is a global instance. Applying The Pattern Global variables have been around as long as applications.  The uses are countless, and some of those are even good programming practices.  However, there are a lot of applications of global values that are due to laziness or at least sloppy coding.  I will not go into all of the pros and cons of global values here (although they are touched on in the podcast). The pattern is simple to implement.  You set the constructors all to private access and then create a "getInstance"  method.  When "getInstance" is called it either creates an instance and returns that, or it returns the current instance.  You will often see the one instance as a private property of the class, or it can even be a static property in some cases. Java, PHP, C#, etc. Java uses singletons for some of the utility functions and to hold methods that need no properties.  Of course, this can also be done with static classes and methods.  That takes away some of the need for a Singleton.  When your language does not support static methods and classes, then you may be forced to go the singleton route. A good use of this pattern is when you truly need to store values, and the object they represent will only ever have one instance in the scope of an application.  A log file or logging system may be configured this way or a similar serial processing structure.  User and session values may require a singleton.  On the other hand, you may find yourself limited if you only allow a single session or user in the application.  This works on a desktop application but is rarely going to work on a web application.  Take a look at the arguments for and against using a singleton before you dive in with this particular pattern.

There are no comments yet.

Please log in to write the first comment.