design patterns in java chapter 8 singleton
DESCRIPTION
Design Patterns in Java Chapter 8 Singleton. Summary prepared by Kirk Scott. Singleton. Objects in general should be responsible for themselves That means that they should be internally consistent It also means that they are self-sufficient - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/1.jpg)
1
Design Patterns in JavaChapter 8Singleton
Summary prepared by Kirk Scott
![Page 2: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/2.jpg)
2
Singleton
• Objects in general should be responsible for themselves
• That means that they should be internally consistent
• It also means that they are self-sufficient• They do not depend (on the whole) on other
classes/objects• They do not implement their functionality by
referring to other classes/objects
![Page 3: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/3.jpg)
3
• In modeling a real problem domain, it can happen that for a given class there will be only one instance
• This situation is known as a singleton• Whether or not there are one or more instances
of a given class sounds like a construction question
• The book’s justification for categorizing singleton with the responsibility patterns follows
![Page 4: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/4.jpg)
4
• Accept as a given that whether classes/objects rely on each other for responsibility, all classes/objects in an application are connected to each other in one way or another
• If there is a singleton, this suggests that responsibility for the singleton is centralized in it
• By extension, this means that any other class/object that deals with the singleton is dependent on the singleton
• In other words, in the context of the whole application, responsibility has been centralized
![Page 5: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/5.jpg)
5
• Book definition:• The intent of the Singleton pattern is to ensure
that a class has only one instance and to provide a global point of access to it.
• Comment mode on:• Note that this statement of intent doesn’t really
include any hint of the justification given earlier for classifying the pattern as a responsibility pattern
![Page 6: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/6.jpg)
6
• The authors now concede that maybe there is a slight mismatch between this pattern and its classification
• They state, “The mechanics of Singleton are more memorable than its intent.”
• Actually, I think what they really mean is that the so-called statement of intent is really a statement of mechanics
• The claimed intent of centralizing responsibility was a bunch of preceding blah blah blah
![Page 7: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/7.jpg)
7
• The authors go on to mention that the original Design Patterns book categorized Singleton as a “creational” pattern
• In other words, other authors, equally competent in the field, have classified patterns more by their structure and syntactical consequences
• It doesn’t matter how Singleton is classified• It would be perfectly legitimate to consider
Singleton a “construction” pattern
![Page 8: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/8.jpg)
8
• It is simply worthwhile to remember the pattern and understand where it might be useful to apply it
• Incidentally, as with other patterns, it is also worth noting some of the implementation “tricks” that the authors reveal
• The authors now jump into the nuts and bolts of implementation
![Page 9: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/9.jpg)
9
• Challenge 8.1• How can you prevent other developers from
constructing new instances of your class?
![Page 10: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/10.jpg)
10
• Solution 8.1• To prevent other developers from instantiating
your class, create a single constructor with private access. Note that if you create other, nonprivate constructors or no constructors at all, other objects will be able to instantiate your class
![Page 11: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/11.jpg)
11
• Comment mode on:• The idea of a private constructor has not come
up before• If you have a private constructor, the question
becomes, how and where do you call it from?• There is some muddling in the book’s
explanation of all this which I will straighten out before finishing with the topic
![Page 12: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/12.jpg)
12
• The book phrases the question of how and where to construct as, “…when to instantiate the single object…”
• The authors then propose that there be a SystemStartup class in a software system which contains the following combined instance variable declaration and construction
• private static Factory factory = new Factory();
![Page 13: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/13.jpg)
13
• I am convinced the authors have gone slightly off the track here
• If the constructor for Factory is private, it couldn’t be called in the SystemStartup class code
• The next statement they make is that “this class” could make its instance variable available through a public getFactory() method
![Page 14: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/14.jpg)
14
• Ignore the SystemStartup class for a moment• In skeletal form, the Factory class definition on
the following overhead appears to be the solution that the authors are proposing
• The Factory class contains a default constructor which is declared private
![Page 15: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/15.jpg)
15
• public class Factory• {• private static Factory factory = new Factory();• private Factory()• {• }• public static getFactory()• {• return factory;• }• }
![Page 16: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/16.jpg)
16
• The class contains a static instance of itself as an instance variable
• The variable is constructed (once) in the declaration by a call to the private constructor
• The class also contains a static getFactory() method which returns a reference to the singleton
• The call to the get method in a client piece of code would be like any call to a static method:
• Factory singletonReference = Factory.getFactory();
![Page 17: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/17.jpg)
17
• The book’s solution works• Not having considered the possibility of
private constructors or classes containing instance variables which are instances of themselves, this is not the first solution approach that would have occurred to me
• I would have been thinking along different lines
![Page 18: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/18.jpg)
18
• The following overhead shows a starting approach to solving the problem
• Notice that it is incomplete• You are stopped when you realize that a
constructor is a constructor
![Page 19: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/19.jpg)
19
• /* An approach to creating a singleton that doesn’t work. */
• public class Factory• {• private static int instanceCount = 0;• public Factory()• {• if(instanceCount == 0)• // do the construction• else• // don’t do the construction• }• }
![Page 20: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/20.jpg)
20
• Within the code for a constructor it is not possible to make the construction conditional like for a method
• It’s not like a method where you have a choice of either returning a reference or returning null
• Once the constructor is called, a new object is created and will be returned
• All that’s taken care of in the body of a constructor is the initialization of the instance variables
![Page 21: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/21.jpg)
21
• However, this is not the end of the story• A constructor, like a method, can be declared
to throw an exception• Then the code can be written either to run
successfully and return a reference to a newly created object
• Or to throw an exception if the conditions for the Singleton design pattern aren’t met
![Page 22: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/22.jpg)
22
• public class Factory• {• private static int instanceCount = 0;• public Factory() throws Exception• {• if(instanceCount == 0)• instanceCount++;• else• throw new Exception(“Uh-oh”);• }• }
![Page 23: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/23.jpg)
23
• Although the previous code isn’t the way the book does it, the code compiles
• The thing client code would have to keep in mind is that a call to the constructor would have to be done in a try/catch block
• This is not an entirely bad solution• It does restrict a class to having at most one
instance
![Page 24: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/24.jpg)
24
• On the other hand, it’s not necessarily an ideal solution
• The point is that it would be convenient to simply be returned a reference to the one existing instance if one has already been created
• This solution puts the burden on the client code of keeping track of whether it’s created an instance before
• If there are >1 client and one creates the instance, then the other client is screwed
![Page 25: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/25.jpg)
25
• Next, the book introduces what it calls lazy initialization
• The idea is that an instance of the Singleton class is only constructed if some piece of client code requests a reference to it
• This requires removing the construction from the line declaring the instance variable
• Construction is then inserted into the getFactory() method
• This is shown on the next overhead
![Page 26: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/26.jpg)
26
• public class Factory• {• private static Factory factory;• private Factory()• {• }• public static getFactory()• {• if(factory == null)• factory = new Factory();• return factory;• }• }
![Page 27: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/27.jpg)
27
• Challenge 8.2• Why might you decide to lazy-initialize a
singleton instance rather than to initialize it in its field declaration?
![Page 28: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/28.jpg)
28
• Solution 8.2• Two reasons for lazy-initializing singletons are
as follows.• 1. You might not have enough information to
instantiate a singleton at static initialization time. For example, a Factory singleton might have to wait for the real factory’s machines to establish communication channels.
![Page 29: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/29.jpg)
29
• 2. You might choose to lazy-initialize a singleton that requires resources, such as a database connection, especially if there is a chance that the containing application will not need the singleton in a particular session.
![Page 30: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/30.jpg)
30
• Whether you lazy initialize or not• Construction of the singleton takes place in
the singleton’s class• And access to the singleton is provided
through a public, static method
![Page 31: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/31.jpg)
31
Singletons and Threads
• CS 320 is not a pre-requisite for CS 304• This subsection depends on understanding
concepts from CS 320, so it is not part of CS 304
• If you have had CS 320, you should be able to read the section and get the idea
![Page 32: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/32.jpg)
32
• Suppose that you do lazy initialization• The goal of the getFactory() method is to construct
only one instance• Suppose you have two client threads which can call
getFactory()• If you don’t synchronize on the call to getFactory(),
both threads could run the method concurrently, resulting in the construction of two Factory objects
• This defeats the goal of implementing a singleton
![Page 33: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/33.jpg)
33
• The book proposes a solution that is based on using the lock concept in Java
• Alternative coding solutions are available since Java has lots of stuff in the API related to threads and synchronization
• The book presents sample code, a challenge, and solution code
![Page 34: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/34.jpg)
34
• None of that will be pursued• If you haven’t had CS 320, you can ignore the
whole topic• It has only been addressed briefly here for the
benefit of those who have already taken CS 320
![Page 35: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/35.jpg)
35
Recognizing Singleton
• In an overall design, classes shouldn’t overlap with each other in their content and functionality
• In other words, classes are unique• On the other hand, you can have multiple
instances of one class
![Page 36: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/36.jpg)
36
• Each of the objects is distinct and unique• The objects differ according to the contents of
their instance variables• In general, you can say that the individual
objects are only responsible for themselves, based on the code defined in their class
![Page 37: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/37.jpg)
37
• Then again, it may frequently be the case that in a certain application, only one instance of a given class is constructed
• The thing to keep in mind is that this doesn’t mean that it wouldn’t be possible or useful to construct more than one instance if the circumstances were different
![Page 38: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/38.jpg)
38
• The point of the foregoing discussion is that actual singletons, where more than one instance has to be prevented, are rare
• The trick is learn how to identify that situation• Consider the following UML diagram
![Page 39: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/39.jpg)
39
![Page 40: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/40.jpg)
40
• Challenge 8.4• For each class in Figure 8.1, say whether it
appears to be a singleton class, and why.• Spoiler mode on:• Only one of these classes is a singleton
![Page 41: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/41.jpg)
41
• Solution 8.4• OurBiggestRocket: This class has an
inappropriate name. You would normally model attributes, such as “biggest,” with attributes, not with class names. If a developer must sustain this class, perhaps it is a singleton.
• TopSalesAssociate: This class has the same problem as OurBiggestRocket.
![Page 42: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/42.jpg)
42
• Math: This class is a utility, with all static methods and no instances. It is not a singleton. Note that it does, however, have a private constructor. [Why? I don’t know.]
• System: This is also a utility.
![Page 43: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/43.jpg)
43
• PrintStream: Although the System.out object is a PrintStream object with unique responsibilities, it is not a unique instance of PrintStream, which is not a singleton class.
• PrintSpooler: PrintSpoolers are associated with one or a few printers; it’s unlikely that this is a singleton.
• PrinterManager: At Oozinoz, you have many printers, and you can look up their addresses through the PrinterManager singleton.
![Page 44: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/44.jpg)
44
• The authors say that Singleton is probably the best known pattern
• This may be because it is easy to understand• It may also be because, for C style
programmers, it makes it easy to get around the requirements of object-oriented programming
• A singleton object can serve as a global type of variable
![Page 45: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/45.jpg)
45
• In general, the reason for the existence of a singleton is some restriction in the problem domain
• A singleton shouldn’t be introduced unless a good reason can be found for having one
• Client code, if at all possible, should have no interest in special conditions on the creation of instances of other classes (like singletons)
• If a class is to have subclasses or different versions, singleton won’t work at all
• The restrictions on construction in the superclass will mess up construction in the subclasses
![Page 46: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/46.jpg)
46
Summary
• The Singleton pattern means only one object of a given class will be created
• By definition, this means there is a single, global occurrence of the class
• Lazy initialization can be a useful feature of the implementation of Singleton
• In a multi-threaded environment synchronization has to be used in order to make sure that an implementation of singleton works correctly
![Page 47: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/47.jpg)
47
• Keep in mind that just because there is only one instance of a class in a given application, that doesn’t mean that the singleton pattern is appropriate
• From a pragmatic point of view, this warning is especially apropos if the class has subclasses
• The Singleton pattern centralizes responsibility in a single instance of a class by hiding the constructor and providing a single point of access to object creation
![Page 48: Design Patterns in Java Chapter 8 Singleton](https://reader033.vdocuments.mx/reader033/viewer/2022061612/5681613f550346895dd0a972/html5/thumbnails/48.jpg)
48
The End