CSC/ECE 517 Fall 2012/ch2b 2w53 iv - Revision history

Annice at 02:11, 20 November 2012

2012-11-20T02:11:40Z

← Older revision		Revision as of 02:11, 20 November 2012
Line 1:		Line 1:
	=Singleton, Directory of Sites=		=Singleton, Directory of Sites=
			This article is presented in the form of directory of a number of sites explaining the use of Singleton pattern.Each of the link to the site is accompanied with the topics covered, a brief summary and a highlight of major points covered in the corresponding web page.
	== [http://en.wikipedia.org/wiki/Singleton_pattern Singleton on the Wikipedia] ==		== [http://en.wikipedia.org/wiki/Singleton_pattern Singleton on the Wikipedia] ==

Smahish at 23:20, 19 November 2012

2012-11-19T23:20:31Z

@@ Line 247: / Line 247: @@
 * Derive the singleton class from an interface. This helps while doing unit testing (using Dependency Injection).
-\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
+'''Topics Covered''' :
 == [http://c2.com/cgi/wiki?SingletonPattern Singleton explained on c2.com]==

Smahish: /* Positive and Negative aspects of Singleton */

2012-11-19T22:45:33Z

Positive and Negative aspects of Singleton

← Older revision		Revision as of 22:45, 19 November 2012
Line 233:		Line 233:
	* Inheriting a singleton class should be prohibited.		* Inheriting a singleton class should be prohibited.
	* Singleton takes over static classes on the following shortcomings:		* Singleton takes over static classes on the following shortcomings:
	- Static classes don’t promote inheritance. If your class has some interface to derive from, static classes makes it impossible.		- Static classes don’t promote inheritance. If your class has some interface to derive from, static classes makes it impossible.
	- You cannot specify any creation logic with static methods.		- You cannot specify any creation logic with static methods.
	- Static methods are procedural code.		- Static methods are procedural code.

	'''Negative sides of Singleton''':		'''Negative sides of Singleton''':

Smahish: /* Positive and Negative aspects of Singleton */

2012-11-19T22:44:27Z

Positive and Negative aspects of Singleton

Smahish: /* Positive and Negative aspects of Singleton */

2012-11-19T22:43:04Z

Positive and Negative aspects of Singleton

← Older revision		Revision as of 22:43, 19 November 2012
Line 221:		Line 221:

	{\|		{\|
	\|[[File:6.gif~~\|x300px~~]]		\|[[File:6.gif]]
	\|}		\|}

Line 228:		Line 228:

	{\|		{\|
	\|[[File:7.gif~~\|x300px~~]]		\|[[File:7.gif]]
	\|}		\|}

Smahish: /* Positive and Negative aspects of Singleton */

2012-11-19T22:42:40Z

Positive and Negative aspects of Singleton

← Older revision		Revision as of 22:42, 19 November 2012
Line 215:		Line 215:

	{\|		{\|
	\|[[File:5.gif~~\|x300px~~]]		\|[[File:5.gif]]
	\|}		\|}

Smahish at 22:40, 19 November 2012

2012-11-19T22:40:13Z

@@ Line 162: / Line 162: @@
 == [http://javapapers.com/design-patterns/singleton-pattern/ JavaPaper on Singleton]==
 '''Topics Covered''':
 Strategy for Singleton instance creation, Early and lazy instantiation in singleton pattern, Singleton and Serialization
@@ Line 199: / Line 200: @@
   java.lang.Runtime#getRuntime()
   java.awt.Desktop#getDesktop()
 \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Smahish at 22:21, 19 November 2012

2012-11-19T22:21:54Z

← Older revision		Revision as of 22:21, 19 November 2012
Line 160:		Line 160:

	Protected constructors can be called by subclasses and by other classes in the same package. Because ClassicSingleton and SingletonInstantiator are in the same package (the default package), SingletonInstantiator() methods can create ClassicSingleton instances. This dilemma has two solutions: You can make the ClassicSingleton constructor private so that only ClassicSingleton() methods call it; however, that means ClassicSingleton cannot be subclassed. Sometimes, that is a desirable solution; if so, it's a good idea to declare your singleton class final, which makes that intention explicit and allows the compiler to apply performance optimizations. The other solution is to put your singleton class in an explicit package, so classes in other packages (including the default package) cannot instantiate singleton instances.		Protected constructors can be called by subclasses and by other classes in the same package. Because ClassicSingleton and SingletonInstantiator are in the same package (the default package), SingletonInstantiator() methods can create ClassicSingleton instances. This dilemma has two solutions: You can make the ClassicSingleton constructor private so that only ClassicSingleton() methods call it; however, that means ClassicSingleton cannot be subclassed. Sometimes, that is a desirable solution; if so, it's a good idea to declare your singleton class final, which makes that intention explicit and allows the compiler to apply performance optimizations. The other solution is to put your singleton class in an explicit package, so classes in other packages (including the default package) cannot instantiate singleton instances.

			== [http://javapapers.com/design-patterns/singleton-pattern/ JavaPaper on Singleton]==
			'''Topics Covered''':
			Strategy for Singleton instance creation, Early and lazy instantiation in singleton pattern, Singleton and Serialization

			'''Summary''':
			There are only two points in the definition of a singleton design pattern,
			* There should be only one instance allowed for a class and
			* We should allow global point of access to that single instance.

			The key is not the problem and definition. In singleton pattern, trickier part is implementation and management of that single instance.

			We suppress the constructor and don’t allow even a single instance for the class. But we declare an attribute for that same class inside and create instance for that and return it. [http://javapapers.com/design-patterns/abstract-factory-pattern/ Factory design pattern] can be used to create the singleton instance.

			You need to be careful with multiple threads. If you don’t synchronize the method which is going to return the instance then, there is a possibility of allowing multiple instances in a multi-threaded scenario. Do the synchronization at block level considering the performance issues. In the below example for singleton pattern, you can see that it is threadsafe.

			package com.javapapers.sample.designpattern;
			public class Singleton {
			private static Singleton singleInstance;
			private Singleton() {}
			public static Singleton getSingleInstance() {
			if (singleInstance == null) {
			synchronized (Singleton.class) {
			if (singleInstance == null) {
			singleInstance = new Singleton();
			}
			}
			}
			return singleInstance;
			}

			'''Singleton and Serialization''' : Using [http://javapapers.com/core-java/java-serialization/ serialization], single instance contract of the singleton pattern can be violated. You can serialize and de-serialize and get a new instance of the same singleton class. Using java api, you can implement the below method and override the instance read from the stream. So that you can always ensure that you have single instance.

			ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException;

			'''Usage of Singleton Pattern in Java API''':

			java.lang.Runtime#getRuntime()
			java.awt.Desktop#getDesktop()

	\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/		\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Smahish: /* Simply Singleton */

2012-11-19T22:13:10Z

Simply Singleton

← Older revision		Revision as of 22:13, 19 November 2012
Line 148:		Line 148:
	\|}		\|}

			Other than the lazy initialization process, a classicSingleton class can also implement a protected constructor so client cannot instantiate ClassicSingleton instances; however, you may be surprised to discover that the following code is perfectly legal:

			public class SingletonInstantiator {
			public SingletonInstantiator() {
			ClassicSingleton instance = ClassicSingleton.getInstance();
			ClassicSingleton anotherInstance =
			new ClassicSingleton();
			...
			}
			}

			Protected constructors can be called by subclasses and by other classes in the same package. Because ClassicSingleton and SingletonInstantiator are in the same package (the default package), SingletonInstantiator() methods can create ClassicSingleton instances. This dilemma has two solutions: You can make the ClassicSingleton constructor private so that only ClassicSingleton() methods call it; however, that means ClassicSingleton cannot be subclassed. Sometimes, that is a desirable solution; if so, it's a good idea to declare your singleton class final, which makes that intention explicit and allows the compiler to apply performance optimizations. The other solution is to put your singleton class in an explicit package, so classes in other packages (including the default package) cannot instantiate singleton instances.
	\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/		\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Smahish at 22:06, 19 November 2012

2012-11-19T22:06:55Z

← Older revision		Revision as of 22:06, 19 November 2012
Line 131:		Line 131:
	Here we make the constructor public and use a private field numOfInstance which is incremented for each constructor call. If numOfInstance is zero (no object is yet instantiated), a new object is allowed to made. But, if this value is not zero (there is already an object of Singleton2 class, an exception is thrown.		Here we make the constructor public and use a private field numOfInstance which is incremented for each constructor call. If numOfInstance is zero (no object is yet instantiated), a new object is allowed to made. But, if this value is not zero (there is already an object of Singleton2 class, an exception is thrown.

			== [http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html Simply Singleton] ==

			'''Topics Covered''':
			Capabilities of Singleton pattern,Singleton design pattern class diagram, Example, use of protected constructors.

			'''Summary''':
			The Singleton design pattern addresses all of the previous paragraph's concerns. With the Singleton design pattern you can:
			* Ensure that only one instance of a class is created.
			* Provide a global point of access to the object.
			* Allow multiple instances in the future without affecting a singleton class's clients.

			As in , [http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html#resources Design Patterns], "Ensure a class has a single instance, and provide a global point of access to it"

			{\|
			\|[[File:4.jpg\|x300px]]
			\|}

	\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/		\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

← Older revision		Revision as of 22:44, 19 November 2012
Line 233:		Line 233:
	* Inheriting a singleton class should be prohibited.		* Inheriting a singleton class should be prohibited.
	* Singleton takes over static classes on the following shortcomings:		* Singleton takes over static classes on the following shortcomings:
	1. Static classes don’t promote inheritance. If your class has some interface to derive from, static classes makes it impossible.		- Static classes don’t promote inheritance. If your class has some interface to derive from, static classes makes it impossible.
	2. You cannot specify any creation logic with static methods.		- You cannot specify any creation logic with static methods.
	3. Static methods are procedural code.		- Static methods are procedural code.

	'''Negative sides of Singleton''':		'''Negative sides of Singleton''':
	1.They deviate from the Single Responsibility Principle. A singleton class has the responsibility to create an instance of itself along with other business responsibilities. However, this issue can be solved by delegating the creation part to a factory object.		* They deviate from the Single Responsibility Principle. A singleton class has the responsibility to create an instance of itself along with other business responsibilities. However, this issue can be solved by delegating the creation part to a factory object.
	2. Singleton classes cannot be sub classed.		* Singleton classes cannot be sub classed.
	3. Singletons can hide dependencies. One of the features of an efficient system architecture is minimizing dependencies between classes. This will in turn help you while conducting unit tests and while isolating any part of the program to a separate assembly.		* Singletons can hide dependencies. One of the features of an efficient system architecture is minimizing dependencies between classes. This will in turn help you while conducting unit tests and while isolating any part of the program to a separate assembly.

	However, it is commonly accepted that the singleton can yield best results in a situation where various parts of an application concurrently try to access a shared resource. An example of a shared resource would be Logger, Print Spooler, etc. When designing a singleton, consider the following points:		However, it is commonly accepted that the singleton can yield best results in a situation where various parts of an application concurrently try to access a shared resource. An example of a shared resource would be Logger, Print Spooler, etc. When designing a singleton, consider the following points:
	1. Singleton classes must be memory-leak free. The instance of the singleton class is to be created once and it remains for the lifetime of the application.		* Singleton classes must be memory-leak free. The instance of the singleton class is to be created once and it remains for the lifetime of the application.
	2. A real singleton class is not easily extensible.		* A real singleton class is not easily extensible.
	3. Derive the singleton class from an interface. This helps while doing unit testing (using Dependency Injection).		* Derive the singleton class from an interface. This helps while doing unit testing (using Dependency Injection).