Possible Duplicate:
What is the difference between all-static-methods and applying a singleton pattern?
In C# Static methods has long served a purpose allowing us to call them without instantiating classes. Only in later year have we became more aware of the problems of using static methods and classes.
- They can’t use interfaces
- They can’t use inheritance
- They are hard to test because you can’t make mocks and stubs
Is there a better way ? Obviously we need to be able to access library methods without instantiated classes all the time otherwise our code would become pretty cluttered
One possibly solution is to use a new keyword for an old concept: the singleton. Singleton’s are global instances of a class, since they are instances we can use them as we would normal classes. In order to make their use nice and practical we'd need some syntactic sugar however
Say that the Math class would be of type singleton instead of an actual class. The actual class containing all the default methods for the Math singleton is DefaultMath, which implements the interface IMath. The singleton would be declared as
singleton Math : IMath
{
public Math
{
this = new DefaultMath();
}
}
If we wanted to substitute our own class for all math operations we could make a new class
MyMath that inherits DefaultMath, or we could just inherit from the interface IMath and create a whole new Class. To make our class the active Math class, you'd do a simple assignment
Math = new MyMath();
and voilá! the next time we call Math.Floor it will call your method. Note that for a normal singleton we'd have to write something like Math.Instance.Floor but the compiler eliminates the need for the Instance property
Another idea would be to be able to define a singletons as Lazy so they get instantiated only when they're first called, like
lazy singleton Math : IMath
What do you think, would it have been a better solution that static methods and classes? Is there any problems with this approach?
Addendum
Some points have been raised, that one of the main benefits of static methods is having methods that are "stateless" and thus side-effect free to some extent from a concurrency point of view. I wholeheartedly agree that that's a valid point. However we're mixing two different issues and problems here: One is making some methods invokable and globally accessible without having to explicitly create an instance. The other is having methods that are stateless.
The second problem could be solved by method having something like a stateless keyword that similarily to static prevented them from calling this or perhaps do even more to enforce no side-effecs. With singletons rather than static classes and something like stateless classes and methods I think you'd have the following pro's and con's
Pro's
- "Static" methods in other classes and framework classes could easily be designed to be overridable
- Classes would be easier to test
- Using instances instead of static classes means design patterns work better (things like factories)
- No limitation on inheritance and polymorphism in contrast to static
Cons
- Perhaps slightly worse performance?
- Bad programmers will but everything in singletons to have them globally accessible instead of using dependency injection, perhaps you should only be able to access singleton methods and not properties/fields to avoid global variables :)
- ?
Perhaps Math was a bad example, but imagine if the .Net string methods were inefficient, you could easily replace them with your own using this method. Or some third-party class has has a singleton method that you wanted to alter slightly, you could inherit and alter that method
