I know the title of this post is weird, but just bear with me a moment...
Often time I found myself writing code like UserServices.Instance.DoSomething(...) when using Singleton pattern. And afterward, I keep saying to myself, that's just ugly. How can you rid yourself from the ugly .Instance. or .GetInstance(). or whatever that keep rearing its ugly head? I want to be able to write UserServices.DoSomething(...) instead?
Looking at the desired syntax, one thing that keep popping into my mind is why don't you just change the class to a class with a bunch of static methods (utility class)? That'll solve the problem right?
This led me around the web to find out the answer of why one should use Singleton instead of the utility class? I came across this article. But the argument there is quite weak in my opinion. The author stated that "Utilities lead to a clear division between behavior and data that you should never allow in an object-oriented design." Well, yes, if it is purely a utility class, but there is no reason why can't you have static fields inside the class that you can still act upon through your static methods. You can still maintain state that way and it still fullfills the primary purpose of a singleton which is to have only one "instance" of a particular class. I also found this article (which provides a better argument, I think). In the end of that one, someone eluded that perhaps Singleton is a "legacy" pattern from C++ time since nowaday Java and C# do have static initialization capability that you can depend on to put a class' static fields into certain states before you call any of its static methods. Some other said that it's easier to maintain / reuse. Frankly, at this time I have to admit that I don't have enough experience maintaining / reusing such singleton to see the real benefit of singleton over class with static methods. Maybe some of you do, if so your input on this matter will be much appreciated.
I stumbled across a lot of discussions on this subject, which I won't bored you with. If you wish to pursue the matter, google "singleton vs static", "polymorphic singleton". You'll run into article ranging from why Singleton good and why Singleton is bad (i.e. this).
I even found myself perusing the HeadFirst Design Pattern book. In the Singleton chapter, There are no dumb questions section, I finally found at least a reason that I can accept (still have to be experienced, however) of why you would use singleton instead of static methods (Quoted below).
Q: Can't I just create a class in which all methods and variables are defined as static? Wouldn't that be the same as a Singleton?
A: Yes, if your class is self-contained and doesn't depend on complex initialization. However, because of the way static initializations are handled in Java, this can get very messy, especially if multiple classes are involved. Often this scenario can result in subtle, hard to find bugs involving order of initialization. Unless there is a compelling need to implement your "singleton" this way, it is far better to stay in the object world.
So, who am I to argue with people possesing more experience in this matter.
So, let's go back to the initial problem. How can you rid yourself from writing .Instance everytime you need to refer to your singleton object? I guess you can cache the singleton once inside a class variable and use that instead. Something like UserServices _userServices = UserServices.Instance; and then just use _userServices.methodName(...) instead of calling UserServices.Instance.methodName(...). If you don't like the different name, you can introduce something like UserServices UserServices = UserServices.Instance as your class variable. Then you can call UserServices.methodName(...) from inside your class.
Another way to do this is a hybrid of the normal singleton and static methods, which is to hide the singleton Instance variable itself from getting exposed outside the class / its subclass and expose a bunch of static method that call the Instance.something like the example below:
1: public class UserMapper
3: protected static readonly UserMapper _instance = new UserMapper();
5: protected UserMapper()
7: //Initialize stuffs here...
10: private IUser doLoad(int id)
12: //Do the real loading of the data here...
15: public static IUser Load(int id)
17: return _instance.doLoad(id);
Which way is better? I'll leave it up to you...