What real (i.e. practical) difference exists between a static class and a singleton pattern?
Both can be invoked without instantiation, both provide only one "Instance" and neither of them is thread-safe. Is there any other difference?
This question is related to
design-patterns
static
singleton
static classes usually are used for libraries, singletons are used if I need only one instance of a particular class. From the point of view of memory there are some differences though: usually in the heap there are allocated only objects, the only methods allocated are methods that are current running. a static class has all methods static too and that will be in the heap from begin, so in general the static class consume more memory.
I'll try to rise above the WTMI and WTL;DR responses.
Singletons are an instance of an object... full stop
Your question is fundamentally asking about the difference between a class an an instance of that class. I think that's pretty clear and requires no elaboration.
The singleton's class generally takes steps to ensure construction of one instance; that's smart but it's not required.
Example: var connection = Connection.Instance;
Say this is the Connection class:
public sealed class Connection
{
static readonly Connection _instance = new Connection();
private Connection()
{
}
public static Connection Instance
{
get
{
return _instance;
}
}
}
Note that you can throw an interface on that class and mock it for testing purposes, something you cannot easily do with a static class.
I'm not a great OO theorist, but from what I know, I think the only OO feature that static classes lack compared to Singletons is polymorphism. But if you don't need it, with a static class you can of course have inheritance ( not sure about interface implementation ) and data and function encapsulation.
The comment of Morendil, "The design style embodied in a static class is purely procedural" I may be wrong, but I disagree. In static methods you can access static members, which would be exactly the same as singleton methods accessing their single instance members.
edit:
I'm actually thinking now that another difference is that a Static class is instantiated at program start* and lives throughout the whole life span of the program, while a singleton is explicitly instantiated at some point and can be destroyed also.
* or it may be instantiated at first use, depending on the language, I think.
Another advantage of a singleton is that it can easily be serialized, which may be necessary if you need to save its state to disc, or send it somewhere remotely.
Singleton's are instantiated, it's just there's only one instance ever instantiated, hence the single in Singleton.
A static class can't be instantiated by anything other than itself.
Both can be invoked without instantiation, both provide only one "Instance" and neither of them is thread-safe. Is there any other difference?
The question is wrong, both its statements. Please note: that static class here means nested static class And not a class with only static methods.
I am assuming(i.e. static class meaning nested static class and not a class with only static members) so because if I see most popular Singleton implementation i.e. DCL way, its nothing but static declaration of instance and static method to get the Singleton instance. Its one implementation. So in this case what's the difference between Singleton and a class with only static members. Though other implementations are possible like that using Enum.
Let me correct the statements:
Singleton class can have single instance application-wide. Nested static class can have multiple instance(see the code below as a proof). Read the basics of nested class here.
No class is inherently thread-safe, it has to be made thread-safe programmatically. It can be done for both nested static class and Singleton.
Some more myth busters are below(Most of answers to this question has given these statements so thought it would be good to programmatically prove it):
In the code below you can see that nested static class NestedStaticClass implements interface, extends another class, have instance variable and parameterized constructor.
package com.demo.core;
public class NestedStaticClassTest
{
public static void main(String[] args)
{
OuterClass.NestedStaticClass obj1 = new OuterClass.NestedStaticClass();
OuterClass.NestedStaticClass obj2 = new OuterClass.NestedStaticClass();
if(obj1 == obj2)
{
System.out.println("Both nested static objects are equal....");
}
else
{
System.out.println("NOT EQUAL......");
}
System.out.println(OuterClass.NestedStaticClass.d);
obj1.setD(5);
System.out.println(OuterClass.NestedStaticClass.d);
System.out.println(obj1.sum());
}
}
class OuterClass
{
int a =1;
static int b = 2;
static class NestedStaticClass extends OneClass implements Sample
{
int c = 3;
static int d = 4;
public NestedStaticClass()
{
}
//Parameterized constructor
public NestedStaticClass(int z)
{
c = z;
}
public int sum()
{
int sum = 0;
sum = b + c + d + getE();
return sum;
}
public static int staticSum()
{
int sum = 0;
sum = b + d;
return sum;
}
public int getC()
{
return c;
}
public void setC(int c)
{
this.c = c;
}
public static int getD()
{
return d;
}
public static void setD(int d)
{
NestedStaticClass.d = d;
}
}
}
interface Sample
{
}
class OneClass
{
int e = 10;
static int f = 11;
public int getE()
{
return e;
}
public void setE(int e)
{
this.e = e;
}
public static int getF()
{
return f;
}
public static void setF(int f)
{
OneClass.f = f;
}
}
To expand on Jon Skeet's Answer
The big difference between a singleton and a bunch of static methods is that singletons can implement interfaces (or derive from useful base classes, although that's less common IME), so you can pass around the singleton as if it were "just another" implementation.
Singletons are easier to work with when unit testing a class. Wherever you pass singletons as a parameter (constructors, setters or methods) you can instead substitute a mocked or stubbed version of the singleton.
Here's a good article: http://javarevisited.blogspot.com.au/2013/03/difference-between-singleton-pattern-vs-static-class-java.html
can't override methods, but can use method hiding. (What is method hiding in Java? Even the JavaDoc explanation is confusing)
public class Animal {
public static void foo() {
System.out.println("Animal");
}
}
public class Cat extends Animal {
public static void foo() { // hides Animal.foo()
System.out.println("Cat");
}
}
In summary, I would only use static classes for holding util methods, and using Singleton for everything else.
Edits
static classes are lazy loaded as well. Thanks @jmoreno (When does static class initialization happen?)
method hiding for static classes. Thanks @MaxPeng.
In singleton pattern you can create the singleton as an instance of a derived type, you can't do that with a static class.
Quick Example:
if( useD3D )
IRenderer::instance = new D3DRenderer
else
IRenderer::instance = new OpenGLRenderer
Singleton is better approach from testing perspective. Unlike static classes , singleton could implement interfaces and you can use mock instance and inject them.
In the example below I will illustrate this. Suppose you have a method isGoodPrice() which uses a method getPrice() and you implement getPrice() as a method in a singleton.
singleton that’s provide getPrice functionality:
public class SupportedVersionSingelton {
private static ICalculator instance = null;
private SupportedVersionSingelton(){
}
public static ICalculator getInstance(){
if(instance == null){
instance = new SupportedVersionSingelton();
}
return instance;
}
@Override
public int getPrice() {
// calculate price logic here
return 0;
}
}
Use of getPrice:
public class Advisor {
public boolean isGoodDeal(){
boolean isGoodDeal = false;
ICalculator supportedVersion = SupportedVersionSingelton.getInstance();
int price = supportedVersion.getPrice();
// logic to determine if price is a good deal.
if(price < 5){
isGoodDeal = true;
}
return isGoodDeal;
}
}
In case you would like to test the method isGoodPrice , with mocking the getPrice() method you could do it by:
Make your singleton implement an interface and inject it.
public interface ICalculator {
int getPrice();
}
Final Singleton implementation:
public class SupportedVersionSingelton implements ICalculator {
private static ICalculator instance = null;
private SupportedVersionSingelton(){
}
public static ICalculator getInstance(){
if(instance == null){
instance = new SupportedVersionSingelton();
}
return instance;
}
@Override
public int getPrice() {
return 0;
}
// for testing purpose
public static void setInstance(ICalculator mockObject){
if(instance != null ){
instance = mockObject;
}
test class:
public class TestCalculation {
class SupportedVersionDouble implements ICalculator{
@Override
public int getPrice() {
return 1;
}
}
@Before
public void setUp() throws Exception {
ICalculator supportedVersionDouble = new SupportedVersionDouble();
SupportedVersionSingelton.setInstance(supportedVersionDouble);
}
@Test
public void test() {
Advisor advidor = new Advisor();
boolean isGoodDeal = advidor.isGoodDeal();
Assert.assertEquals(isGoodDeal, true);
}
}
In case we take the alternative of using static method for implementing getPrice() , it was difficult to the mock getPrice(). You could mock static with power mock, yet not all product could use it.
Well a singleton is just a normal class that IS instantiated but just once and indirectly from the client code. Static class is not instantiated. As far as I know static methods (static class must have static methods) are faster than non-static.
Edit:
FxCop Performance rule description:
"Methods which do not access instance data or call instance methods can be marked as static (Shared in VB). After doing so, the compiler will emit non-virtual call sites to these members which will prevent a check at runtime for each call that insures the current object pointer is non-null. This can result in a measurable performance gain for performance-sensitive code. In some cases, the failure to access the current object instance represents a correctness issue."
I don't actually know if this applies also to static methods in static classes.
interface with a Singleton class, but a class's static methods (or e.g. a C# static class) cannot.static classes are not for anything that needs state. It is useful for putting a bunch of functions together i.e Math (or Utils in projects). So the class name just gives us a clue where we can find the functions and nothing more.
Singleton is my favorite pattern and I use it to manage something at a single point. It's more flexible than static classes and can maintain it's state. It can implement interfaces, inherit from other classes and allow inheritance.
My rule for choosing between static and singleton:
If there is a bunch of functions that should be kept together, then static is the choice.
Anything else which needs single access to some resources, could be implemented as a singleton.
I read the following and think it makes sense too:
Taking Care of Business
Remember, one of the most important OO rules is that an object is responsible for itself. This means that issues regarding the life cycle of a class should be handled in the class, not delegated to language constructs like static, and so on.
from the book Objected-Oriented Thought Process 4th Ed.
JDK has examples of both singleton and static, on the one hand java.lang.Math is a final class with static methods, on the other hand java.lang.Runtime is a singleton class.
Advantages of singleton
If your need to maintain state than singleton pattern is better choice than static class, because maintaining state in static class leads to bugs, especially in concurrent environment, that could lead to race conditions without adequate synchronization parallel modification by multiple threads.
Singleton class can be lazy loaded if its a heavy object, but static class doesn't have such advantages and always eagerly loaded.
With singleton, you can use inheritance and polymorphism to extend a base class, implement an interface and provide different implementations.
Since static methods in Java cannot be overridden, they lead to inflexibility. On the other hand, you can override methods defined in singleton class by extending it.
Disadvantages of static class
Advantages of static class
Detailed description each of them is too verbose so I just put a link to a good article - All you want to know about Singleton
There is a huge difference between a single static class instance (that is, a single instance of a class, which happens to be a static or global variable) and a single static pointer to an instance of the class on the heap:
When your application exits, the destructor of the static class instance will be called. That means if you used that static instance as a singleton, your singleton ceased working properly. If there is still code running that uses that singleton, for example in a different thread, that code is likely to crash.
One main advantage for Singleton : Polymorphism Eg : create instance using a Class factory( Say based on some configuration), and we want this object to be really singleton.
A static class is one that has only static methods, for which a better word would be "functions". The design style embodied in a static class is purely procedural.
Singleton, on the other hand, is a pattern specific to OO design. It is an instance of an object (with all the possibilities inherent in that, such as polymorphism), with a creation procedure that ensures that there is only ever one instance of that particular role over its entire lifetime.
In an article I wrote I have described my point of view about why the singleton is much better than a static class:
We can create the object of singleton class and pass it to method.
Singleton class doesn't any restriction of inheritance.
We can't dispose the objects of a static class but can singleton class.
A singleton is nothing more than a write-once static variable on a class that always refers to the same instance of itself once it's initialized.
So, you cannot "use a singleton instead of static variables" nor can you avoid keeping state in static variables by using singletons.
The advantage of a singleton is only this: it does not get reinitialized even if some other code tries to reinitialize it a thousand times. This is great for something like a network handler where, y'know, it would suck if an instance got replaced with another instance in the middle of waiting for a response.
Unless you want an entire app WITH NO INSTANCES ANYWHERE—all static!—then the singleton makes sense for these cases where we cannot rely on a lack of human error as the only guarantee something won't get overwritten.
But beware, singleton is no guarantee against state living everywhere. Your network handler may within itself also rely on other singletons, etc. Now we have state living in a host of singletons... marvelous.
And there is no compiler in existence that will ensure that the singleton is where all your state lives, or any other such ideas, at compile time. You can have a hundred static variables on a class that has a singleton. And the singleton can access the static variables. And the compiler will not care.
So I would caution anyone from assuming that using a singleton guarantees anything at all about where state lives. Its only guarantee is simply that it is the only instance of its class, ever. And that is also its only advantage.
Any other advantages that the other answers claim for singletons are things the compiler does not guarantee and that may vary from language to language. Dependency injection is a supplementary pattern that may rely on a singleton, though it may or may not be the best solution or the only solution in a given language. In languages that lack generics, or that place arbitrary restrictions on calling static accessors and functions, resorting to the singleton pattern may indeed be the best available solution to a given problem.
Singleton is not necessary at all in a language like Swift, to get dependency injection, testable code, well-managed state, thread-safe accessors, polymorphism, etc. However it's still useful for the guarantee of a single instance ever.
To recap: a singleton is nothing more than a static variable that serves as a safeguard against multiple instances of given class existing, and against the single instance being overwritten by a new one. That's it, period, full stop.
As I understand the difference between a Static class and non-Static Singleton class, the static is simply a non-instantiated "type" in C#, where the Singleton is a true "object". In other words, all the static members in a static class are assigned to the type but in the Singleton are housed under the object. But keep in mind, a static class still behaves like a reference type as its not a value type like a Struct.
That means when you create a Singleton, because the class itself isnt static but its member is, the advantage is the static member inside the Singleton that refers to itself is connected to an actual "object" rather than a hollow "type" of itself. That sort of clarifies now the difference between a Static and a Non-Static Singleton beyond its other features and memory usage, which is confusing for me.
Both use static members which are single copies of a member, but the Singleton wraps the referenced member around a true instantiated "object" who's address exists in addition to its static member. That object itself has properties wherein in can be passed around and referenced, adding value. The Static class is just a type so it doesn't exist except to point to its static members. That concept sort of cemented the purpose of the Singleton vs Static Class beyond the inheritance and other issues.
From a client perspective, static behavior is known to the client but Singleton behavior can be completed hidden from a client. Client may never know that there only one single instance he's playing around with again and again.
a. Serialization - Static members belong to the class and hence can't be serialized.
b. Though we have made the constructor private, static member variables still will be carried to subclass.
c. We can't do lazy initialization as everything will be loaded upon class loading only.
We have our DB framework that makes connections to Back end.To Avoid Dirty reads across Multiple users we have used singleton pattern to ensure we have single instance available at any point of time.
In c# a static class cannot implement an interface. When a single instance class needs to implement an interface for a business contracts or IoC purposes, this is where I use the Singleton pattern without a static class
Singleton provides a way to maintain state in stateless scenarios
Hope that helps you..
In many cases, these two have no practical difference, especially if the singleton instance never changes or changes very slowly e.g. holding configurations.
I'd say the biggest difference is a singleton is still a normal Java Bean as oppose to a specialized static-only Java class. And because of this, a singleton is accepted in many more situations; it is in fact the default Spring Framework's instantiation strategy. The consumer may or may not know it's a singleton being passed around, it just treat it like a normal Java bean. If requirement changes and a singleton needs to become a prototype instead, as we often see in Spring, it can be done totally seamlessly without a line of code change to the consumer.
Someone else has mentioned earlier that a static class should be purely procedural e.g. java.lang.Math. In my mind, such a class should never be passed around and they should never hold anything other than static final as attributes. For everything else, use a singleton since it's much more flexible and easier to maintain.
I'm agree with this definition:
The word "single" means single object across the application life cycle, so the scope is at application level.
The static does not have any Object pointer, so the scope is at App Domain level.
Moreover both should be implemented to be thread-safe.
You can find interesting other differences about: Singleton Pattern Versus Static Class
Main differences are:
A static class in Java has only static methods. It is a container of functions. It is created based on procedural programming design.
Singleton class is a pattern in Object Oriented Design. A Singleton class has only one instance of an object in JVM. This pattern is implemented in such a way that there is always only one instance of that class present in JVM.
To illustrate Jon's point what's shown below cannot be done if Logger was a static class.The class SomeClass expects an instance of ILogger implementation to be passed into its constructor.
Singleton class is important for dependency injection to be possible.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ConsoleApplication2
{
class Program
{
static void Main(string[] args)
{
var someClass = new SomeClass(Logger.GetLogger());
}
}
public class SomeClass
{
public SomeClass(ILogger MyLogger)
{
}
}
public class Logger : ILogger
{
private static Logger _logger;
private Logger() { }
public static Logger GetLogger()
{
if (_logger==null)
{
_logger = new Logger();
}
return _logger;
}
public void Log()
{
}
}
public interface ILogger
{
void Log();
}
}
The Singleton pattern has several advantages over static classes. First, a singleton can extend classes and implement interfaces, while a static class cannot (it can extend classes, but it does not inherit their instance members). A singleton can be initialized lazily or asynchronously while a static class is generally initialized when it is first loaded, leading to potential class loader issues. However the most important advantage, though, is that singletons can be handled polymorphically without forcing their users to assume that there is only one instance.
Static Class:-
You cannot create the instance of static class.
Loaded automatically by the .NET Framework common language runtime (CLR) when the program or namespace containing the class is loaded.
Static Class cannot have constructor.
We cannot pass the static class to method.
We cannot inherit Static class to another Static class in C#.
A class having all static methods.
Better performance (static methods are bonded on compile time)
Singleton:-
You can create one instance of the object and reuse it.
Singleton instance is created for the first time when the user requested.
Singleton class can have constructor.
You can create the object of singleton class and pass it to method.
Singleton class does not say any restriction of Inheritance.
We can dispose the objects of a singleton class but not of static class.
Methods can be overridden.
Can be lazy loaded when need (static classes are always loaded).
We can implement interface(static class can not implement interface).
Singleton class provides an object(only one instance) during the application lifeCycle such as java.lang.Runtime
While Static class only provide static methods such as java.lang.Math
Static methods in Java cannot be overridden, but methods defined in Singleton class can be overridden by extending it.
Singleton Class is capable of Inheritance and Polymorphism to extend a base class, implement an interface and capable of providing different implementations. whereas static not.
For eg: java.lang.Runtime,is a Singleton Class in Java, call to getRuntime() method returns the runtime object associated with the current Java application but ensures only one instance per JVM.
When I want class with full functionality, e.g. there are many methods and variables, I use singleton;
If I want class with only one or two methods in it, e.g. MailService class, which has only 1 method SendMail() I use static class and method.
The true answer is by Jon Skeet, on another forum here.
A singleton allows access to a single created instance - that instance (or rather, a reference to that instance) can be passed as a parameter to other methods, and treated as a normal object.
A static class allows only static methods.
Example with a static class
public class Any {
private static Any instance = new Any();
private Singleton() {
System.out.println("creating");
}
}
with singleton patterns only exist one instance:
public class Singleton {
private static Singleton instance = new Singleton();
private Singleton() {
System.out.println("creating");
if (instance != null) {
throw new RuntimeException("Imposible create a new instance ");
}
}
}
The difference in my head is implementing object oriented programming (Singleton/Prototype) or functional programming(Static).
We are too focused on the number of objects created by singleton pattern when what we should focus on is that in the end we hold an object. Like others have already said, it can be extended, passed as a parameter but most importantly it is state-full.
On the other hand static is used to implement functional programming. The static members belongs to a class. They are stateless.
By the way did you know that you can create singleton static classes :)
One notable difference is differed instantiation that comes with Singletons.
With static classes, it gets created by the CLR and we have not control on it. with singletons, the object gets instantiated on the first instance it's tried to be accessed.
Source: Stackoverflow.com