What is the Singleton?<\/h2>\n
As described in the Design Patterns book, the purpose of the Singleton is described as such:<\/p>\n
Ensure a class only has one instance, and provide a global point of access to<\/em> This is\u00a0pretty\u00a0<\/em>straightforward but doesn’t lend much in way of motivation for such a pattern. Fortunately, Movitation\u00a0<\/em>happens to be the name of the next section in the book, which elaborates as such:<\/p>\n It’s important for some classes to have exactly one instance. Although there can<\/em> The book continues by describing the common use-case of which the Singleton offers a robust alternative:<\/p>\n How do we ensure that a class has only one instance and that the instance is easily <\/em>accessible? A global variable makes an object accessible, but it doesn’t keep<\/em> There it is: avoiding duplicate objects while providing global access to certain variables. Global variables are inherently dangerous, regarded by many as code smells<\/a>, and can easily alter a system in unforeseen ways.<\/p>\n The Singleton pattern is clearly useful but its overuse can provide as much trouble as its correct use can provide benefit. Knowing the implications of the Singleton, especially the circumstances in which it’s best suited, can help avoid potentially disastrous conflicts and bugs. In the original outline of the Singleton, the Gang of Four describe the most appropriate conditions in which the Singleton can be used:<\/p>\n Two conditions\u2014simple enough, right? The Singleton can cause some issues when used improperly, or even properly (unit testing, parallel testing, added dependencies, etc.) Nonetheless, the benefits still outweigh the potential downsides in many cases. Let’s consider some of the more prominent Singleton benefits.<\/p>\n In the Design Patterns book, the Gang of Four outlines several obvious benefits of the Singleton. These benefits explained as high-level concepts, do not guarantee conflict-free implementation by any means.<\/p>\n Rather the following benefits are meant as guidelines to help developers understand the potential\u00a0<\/em>benefits the Singleton has to offer when used appropriately.<\/p>\n These benefits of the Singleton pattern make it sound like a sure-fire winner. However, one might notice that there isn’t a\u00a0lot<\/em> of direction on just how these benefits might be realized through implementation. Let’s consider what the implementation of a Singleton class actually looks like.<\/p>\n In terms of class complexity, the Singleton is pretty straightforward to implement. No interfaces, no inheritance, nothing fancy but ensuring that an attribute for holding a class instance and method for accessing that instance. In fact, the UML representation of a Singleton doesn’t offer much insight at all as to the nature of its implementation! Let’s look at some code:<\/p>\n In the code above, you may notice several oddities characterized by static methods, private constructors, and Factory-Pattern-like instantiation. These are the basic requirements for the Singleton pattern to ensure it behaves as intended. Let’s consider each method and attribute a bit more.<\/p>\n The The use of a private static variable here ensures that only the Singleton class has access. Given this is the attribute that will hold a reference to our single global instance, we don’t want other class objects to have direct access.<\/p>\n The Singleton’s sole constructor method is This is the heart and soul of the Singleton and determines when to create a new Singleton instance and when to return an existing one. If another class instance calls the With a few additions to the code above we can see how the Singleton class behaves. Consider the following additions:<\/p>\n This code, inserted just below our Singleton class’ declaration, provides a new String variable in which a message is stored. This message is accessed via standard getter and setter methods. We can demonstrate the functionality of the class with the following code:<\/p>\n This code does the following actions:<\/p>\n This results in the following output being printed to the console screen:<\/p>\n On line one, we see the default message encoded into the Singleton class. On the second line, we see the new message we’ve set via the But why? When we create the The Singleton Pattern is one that is implemented across many application systems across many different programming languages<\/a>. It provides convenient access on a global scale while limiting namespace, is extensible, and can even allow for a controlled variable number of instances if desired.<\/p>\n The Singleton is used in applications for logging, game environments to help manage scenes, and many other applications. There’s a growing conversation focused on the overuse and\/or misuse of the Singleton pattern<\/a>. I think there exists the possibility to misuse any design pattern and the Singleton is no exception. Knowing\u00a0what<\/em> it is,\u00a0when<\/em> others use it, and\u00a0how<\/em> to implement it can help determine if it is appropriate for a given application.<\/p>\n
\nit.<\/em><\/p>\n
\nbe many printers in a system, there should be only one printer spooler. There<\/em>
\nshould be only one file system and one window manager\u00a0<\/em><\/p>\n
\nyou from instantiating multiple objects.<\/em><\/p>\nWhen is the Singleton Used?<\/h2>\n
\n
Benefits of the Singleton Pattern<\/h2>\n
\n
Implementing the Singleton<\/h2>\n
![\"singleton](\"https:\/\/www.alpharithms.com\/wp-content\/uploads\/778\/singleton-pattern-uml-diagram-overcoded.jpg\" "\\"singleton-pattern-uml-diagram-overcoded\\"")
<\/a><\/p>\n\/**\r\n * A basic implementation of the Singleton pattern such \r\n * that only a single instance of the class may be \r\n * present in the application.\r\n *\/\r\npublic class Singleton {\r\n\r\n \/\/ A private static method that holds the \r\n \/\/ single instance of the Singleton, if \r\n \/\/ one has been instantiated anywhere.\r\n private static Singleton _instance = null;\r\n\r\n \/**\r\n * Private constructor to prevent instantiation of \r\n * Single objects from anywhere other than this Class.\r\n *\/\r\n private Singleton(){}\r\n\r\n \/**\r\n * Method to return the current instance of the Singleton\r\n * class if one has been instantiated or, if not, create\r\n * and return the new one.\r\n * @return Singleton - the single globally-accessible instance\r\n *\/\r\n public static Singleton getInstance(){\r\n if(_instance == null){\r\n _instance = new Singleton();\r\n }\r\n return _instance;\r\n }\r\n}<\/pre>\nStatic Attribute: _instance<\/h3>\n
_instance<\/code> attribute is defined as both static<\/code> and<\/em> private<\/code>. This is a strange combination\u2014given that static accessors are generally defined as public<\/code> and would default to package-private<\/code> if no accessor were specified (the same as classes in Java<\/a>).<\/p>\nPrivate Constructor<\/h3>\n
private<\/code> which means no other class object can create a new instance via conventional means as new Singleton()<\/code>;. Instead, the privatization of the constructor ensures only the Singleton class can create a new instance\u2014with full control of the means of how such is done.<\/p>\nThe getInstance Method<\/h3>\n
getInstance<\/code> method it will be given the existing Singleton instance, if it exists, or will trigger the Singleton class to create a new class instance and return that.<\/p>\nThe Singleton in Action<\/h2>\n
\/\/ A variable to hold a String message\r\nString message = \"Hello, my name is Singleton.\";\r\n\r\n\/**\r\n * Getter method to return instance message\r\n * @return String - Message currently held by Singleton\r\n *\/\r\npublic String getMessage() {\r\n return message;\r\n}\r\n\r\n\/**\r\n * Setter method to change the current message\r\n * @param message String - value to change the message to.\r\n *\/\r\npublic void setMessage(String message) {\r\n this.message = message;\r\n}\r\n<\/pre>\n\/**\r\n * A simple example driver to illustrate the basic operations of\r\n * the Single class.\r\n *\/\r\npublic static void main(String[] args) {\r\n\r\n \/\/ Create a new Singleton object via static method\r\n Singleton singleton = Singleton.getInstance();\r\n\r\n \/\/ Print the message to standard output\r\n System.out.println(singleton.getMessage());\r\n\r\n \/\/ Create a new singleton object\r\n Singleton singletonTwo = Singleton.getInstance();\r\n\r\n \/\/ Create a unique message for the second Singleton\r\n singletonTwo.setMessage(\"Hello, my name is SingletonTwo\");\r\n\r\n \/\/ Print the message of the second Singleton\r\n System.out.println(singletonTwo.getMessage());\r\n\r\n \/\/ Print the message of the first Singleton again (it changed!)\r\n System.out.println(singleton.getMessage());\r\n\r\n}<\/pre>\n\n
Hello, my name is Singleton.\r\nHello, my name is SingletonTwo\r\nHello, my name is SingletonTwo<\/pre>\n
singletonTwo<\/code> object. On the third line, we attempt to print out the initial message from our first singleton object. However, this time we get the message from the singletonTwo<\/code> object!<\/p>\nsingletonTwo<\/code> object we are really just given the same instance as assigned in the first singleton variable. So when we update the message of the second object, we’re really updating the message of both\u2014because they reference the same\u00a0single\u00a0<\/em>instance!<\/strong><\/p>\nFinal Thoughts<\/h2>\n