I was searching the difference between singleton & static classes and I got many difference, but some of them are not very clear.
All the differences as following
(The answers were quoted from this question.)
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 is not actually canonical class – it’s a namespace with functions and variables
- Using static class is not a good practice because of breaking object-oriented programming principles
- Static class cannot be passed as a parameter for other
- Static class is not suitable for “lazy” initialization
- Initialization and using of static class is always hard tracked
- Multiple threads management is implemented hard
source by user2604650
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.
- Singleton object stores in Heap but, static object stores in stack
- We can clone the object of Singleton but, we can not clone the static class object
- Singleton class follow the OOP(object oriented principles) but not static class
- we can implement interface with Singleton class but not with Static class.
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.
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
source by RK Muddala
Ability to return derived type (as a combination of lazyloading and interface implementation)
singleton is that it can easily be serialized
What does it mean?
singleton can extend classes and implement interfaces, while a static class cannot (it can extend classes, but it does not inherit their instance members).
what is the meaning of Ability to return derived type
Just discuss the above 2 points.
A few guys said they use singleton design pattern for their db connection it means only one connection exist in whole application and that single connection give the service to all request. I just like to know single connection can handle multiple db related request?
please guide me that should we follow singleton pattern for db connection handling....if not then please write all the pros & corns. thanks
Don't use a singleton for database connections. Probably don't use singletons at all, they are heavily overused, provide very little benefit and cause trouble on their own. If you really want to use a singleton don't bother making it lazy because that is difficult and buys you even less. Using dependency injection is usually a much better way to solve the problem.
If you use Microsoft SQL Server .NET manages a connection pool for you [1] and there is usually no good reason you have to care about the details of creating, destroying and reusing connections to the server.
Microsoft SQL Server 2005 and later support Multiple Active Result Sets (MARS) [2] and so you are indeed able to run several queries using the same connection.
Things will obviously look different for other databases. I can elaborate on specific questions but the whole thing about static classes, singletons, resource locators and dependency injection is just to broad to be dealt with in one answer.
[1] http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx
[2] http://msdn.microsoft.com/en-us/library/cfa084cz.aspx
To answer your questions:
- Singletons are first-and-foremost objects. As such, all the inheritance stuff applies to them as well. Static classes on the other hand are just containers for static functions (and static state). As static members will not be inherited when subtyping types, they do not benefit from inheritance at all. Interfaces also do not allow specifying static members, so you cannot use them either for static classes.
- “Ability to return derived types” is a direct implication of the fact that singletons are objects. As objects, you can pass them to or return them from methods. This means that methods working with those singleton objects do not actually need to know that they are using singletons. Adding to that, you can use an interface type instead of the concrete singleton type. This allows for loose coupling, and makes the code more robust in general, as you can easily exchange that singleton object by some other object which provides the same functionality (by implementing the interface). So this is a good way to get rid of singletons in the long run and use things like dependency injection as a form of inversion of control.
As for database connections, using singletons to maintain a permanent connection that is reused everywhere does make some kind of sense. However, there is usually a different approach in the .NET framework: That approach involves short-living connections that are only used for the very specific short duration a database connection is actually required. So instead of keeping the connection alive all the time, you create the connection, perform your query, and immediately close the connection.
Of course, permanently opening and closing database connections involves some drawback. To compensate that, the .NET frameworks uses a pooling strategy which keeps a number of connections around to be “created” quickly with a very small overhead. So instead of actually creating a real connection from scratch, you get an existing connection from the connection pool, work with it, and then release it back to the connection pool.
// create a new connection
using (var connection = new SqlConnection())
{
// work with the connection
doSomethingWith(connection);
}
// connection is now automatically closed and returned to the connection pool
I was searching the difference between singleton & static classes and I got many difference, but some of them are not very clear.
All the differences as following
(The answers were quoted from this question.)
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 is not actually canonical class – it’s a namespace with functions and variables
- Using static class is not a good practice because of breaking object-oriented programming principles
- Static class cannot be passed as a parameter for other
- Static class is not suitable for “lazy” initialization
- Initialization and using of static class is always hard tracked
- Multiple threads management is implemented hard
source by user2604650
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.
- Singleton object stores in Heap but, static object stores in stack
- We can clone the object of Singleton but, we can not clone the static class object
- Singleton class follow the OOP(object oriented principles) but not static class
- we can implement interface with Singleton class but not with Static class.
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.
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
source by RK Muddala
Ability to return derived type (as a combination of lazyloading and interface implementation)
singleton is that it can easily be serialized
What does it mean?
singleton can extend classes and implement interfaces, while a static class cannot (it can extend classes, but it does not inherit their instance members).
what is the meaning of Ability to return derived type
Just discuss the above 2 points.
A few guys said they use singleton design pattern for their db connection it means only one connection exist in whole application and that single connection give the service to all request. I just like to know single connection can handle multiple db related request?
please guide me that should we follow singleton pattern for db connection handling....if not then please write all the pros & corns. thanks
Don't use a singleton for database connections. Probably don't use singletons at all, they are heavily overused, provide very little benefit and cause trouble on their own. If you really want to use a singleton don't bother making it lazy because that is difficult and buys you even less. Using dependency injection is usually a much better way to solve the problem.
If you use Microsoft SQL Server .NET manages a connection pool for you [1] and there is usually no good reason you have to care about the details of creating, destroying and reusing connections to the server.
Microsoft SQL Server 2005 and later support Multiple Active Result Sets (MARS) [2] and so you are indeed able to run several queries using the same connection.
Things will obviously look different for other databases. I can elaborate on specific questions but the whole thing about static classes, singletons, resource locators and dependency injection is just to broad to be dealt with in one answer.
[1] http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx
[2] http://msdn.microsoft.com/en-us/library/cfa084cz.aspx
To answer your questions:
- Singletons are first-and-foremost objects. As such, all the inheritance stuff applies to them as well. Static classes on the other hand are just containers for static functions (and static state). As static members will not be inherited when subtyping types, they do not benefit from inheritance at all. Interfaces also do not allow specifying static members, so you cannot use them either for static classes.
- “Ability to return derived types” is a direct implication of the fact that singletons are objects. As objects, you can pass them to or return them from methods. This means that methods working with those singleton objects do not actually need to know that they are using singletons. Adding to that, you can use an interface type instead of the concrete singleton type. This allows for loose coupling, and makes the code more robust in general, as you can easily exchange that singleton object by some other object which provides the same functionality (by implementing the interface). So this is a good way to get rid of singletons in the long run and use things like dependency injection as a form of inversion of control.
As for database connections, using singletons to maintain a permanent connection that is reused everywhere does make some kind of sense. However, there is usually a different approach in the .NET framework: That approach involves short-living connections that are only used for the very specific short duration a database connection is actually required. So instead of keeping the connection alive all the time, you create the connection, perform your query, and immediately close the connection.
Of course, permanently opening and closing database connections involves some drawback. To compensate that, the .NET frameworks uses a pooling strategy which keeps a number of connections around to be “created” quickly with a very small overhead. So instead of actually creating a real connection from scratch, you get an existing connection from the connection pool, work with it, and then release it back to the connection pool.
// create a new connection
using (var connection = new SqlConnection())
{
// work with the connection
doSomethingWith(connection);
}
// connection is now automatically closed and returned to the connection pool
0 commentaires:
Enregistrer un commentaire