PDA

View Full Version : Singleton pattern vs Static classes



sinpin
جمعه 23 آذر 1386, 15:35 عصر
بدلیل آنکه این سئوال در چندین پست و در تاپیکهای مختلف مطرح شده بود من این تاپیک رو بصورت مستقل ایجاد کردم.
سایر دوستان نیز اگر نظری دارند لطفا همینجا اعلام کنند.
مرسی !

منبع :
http://my.opera.com/zomg/blog/2007/0...ses?prevpoll=1 (http://my.opera.com/zomg/blog/2007/09/17/singleton-pattern-vs-static-classes?prevpoll=1)


It's much simpler to create and access static classes than singleton classes, too.

The singleton does have some advantages though...


With Singleton, you can keep track of who's using it easily. This is because you need to call the getInstance() or whatever method which returns an instance of the class.

Also, because of the above, you can control the amount of actual instances. In some special cases, it might be useful to have multiple instances of the singleton class, for example for load balancing.


You can also give a singleton some parameters. When working with static classes, you may need to pass a lot of parameters to the methods of the class because you aren't "constructing" it. This can, however, be avoided by using a method in the static class that saves the parameters and calling the method you want after that which is pretty much equal to first calling the singleton's getInstance with your parameters and then calling its method.


Singleton also gives a reference/pointer to the class instance. You can then pass this reference as a parameter for some other function for example. If you were using static classes, the other function would have to use the class statically too and if you ever needed to change the behavior, you would need to rewrite parts of that function too instead of just having the first one pass a different class as the parameter.

There's also an another side to the reference thing. If you use the reference in your class and decide that you won't need a singleton anymore, but a normal class, you will just need to change the behavior of the class itself and perhaps replace the line which gets an instance of it to constructing a new one or such. If you were using a static class, you would have to rewrite a lot of the code to use the new reference to the class instead of the static class name. A singleton class should also work almost out of the box as a normal class too. If you had a static class and wanted to convert it to a normal one, you would have to rewrite many parts of it.


You can't extend static classes, but singletons you can. Except it doesn't work very well in PHP due to some issues with static method inheritance, but it's not the only language in the world and it can be done but slightly hackily.



So if we think about it with all this, why would you use static classes at all?
They have their uses too - For example for library code they can be nice, such as the static System.Math class in C#.

sinpin
جمعه 23 آذر 1386, 15:36 عصر
منبع : http://www.cs.colorado.edu/~kena/classes/6448/s05/singletonStatic.html (http://www.cs.colorado.edu/%7Ekena/classes/6448/s05/singletonStatic.html)

البته این مقایسه در جاوا انجام گرفته اما منطق یکی است.


Singleton Design Pattern vs. Static Packages

In lecture 13, a question was asked about the difference between using the Singleton design pattern and making use of a class consisting entirely of static methods and member variables. In other words, what is the difference between this:


public class Singleton {
private static Singleton instance;

private Date d;

private Singleton() {
d = new Date();
}

public synchronized static Singleton instance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}

public Date getDate() {
return d;
}
}
and this:


public class Singleton {

private static Date d = new Date();

public static Date getDate() {
return d;
}
}
Both are functionally equivalent, in that only one instance of the date value is ever created and you can retrieve that one instance. But, there are a few differences that can be highlighted that may push you towards using the Singleton design pattern. To wit:
The first difference is largely conceptual. The static package approach is too similar to procedural based programming. In OO, the modus operandi is objects; and we should stick with objects in our analysis, design, and implementation as much as possible.
The second difference is one I mentioned in class: its a "shorter hop" to the variation of the singleton pattern that allows n instances of an object to be created, with:
0 < n < upper bound
when you start with the singleton pattern than with the static package approach.
The third difference is that if you wanted to allow the creation of several subclasses of the original Singleton class and then choose at run-time which subclass was going to be instantiated and then allow only one of those instances to be created, you would need to start with the singleton pattern.
Finally, a fourth difference was pointed out to me by Ryan G. Dejana, a CAETE student who works for IBM. Ryan points out that static methods are not polymorphic. So, if you tried to simulate this design pattern with the static package approach and had subclasses of the original "Singleton" class, you might run into unexpected behavior. The following three classes demonstrate the problem:


public class Test {

public static String getMessage(){
return getString();
}

protected static String getString(){
return "Hello from Test";
}

}

public class Test2 extends Test {
protected static String getString(){
return "Hello from Test2";
}
}

public class Main {

public static void main(String[] args) {
System.out.println(Test2.getMessage());
}

}
The output of Main is "Hello from Test" and not "Hello From Test2"

sinpin
جمعه 23 آذر 1386, 15:37 عصر
منبع : http://en.wikipedia.org/wiki/Singleton_pattern (http://en.wikipedia.org/wiki/Singleton_pattern)


The singleton pattern is implemented by creating a class (http://en.wikipedia.org/wiki/Class_%28computer_science%29) with a method that creates a new instance of the class if one does not exist. If an instance already exists, it simply returns a reference to that object. To make sure that the object cannot be instantiated any other way, the constructor (http://en.wikipedia.org/wiki/Constructor) is made either private or protected. Note the distinction between a simple static instance of a class and a singleton: although a singleton can be implemented as a static instance, it can also be lazily constructed, requiring no memory or resources until needed. Another notable difference is that static member classes cannot implement an interface, unless that interface is simply a marker. So if the class has to realize a contract expressed by an interface, you really have to make it a singleton.