SingleTon in Client

[Ramesh kumaar]

Dear All,
I have implemented singleton pattern almost in all my client side class, especially in my ModelClass, ViewClass, Controller. I doubt wheather its a good design. Please comment on this.
thanks & regards,
rameshkumar

[Peter den Haan]

The Singleton is the most abused design pattern there is. The Singleton pattern is appropriate when there is a fundamental, inherent reason why you should not have more than one copy of an object in the entire JVM. So what does this mean in the context of the assignment?

It can make sense to make the model a Singleton. After all, the whole point of MVC is that you have a single repository for the state -- the model -- and potentially multiple views and multiple controllers operating on it.

By the same token, turning view and controller into a Singleton is probably not a good idea, even though you happen to need only a single copy of each in this application. The key phrase is happen to. The fact that you happen to need just one copy is not a fundamental reason and not a valid reason to use the Singleton pattern. Using it may well make future enhancements of the application that do present multiple views more difficult.

Along the same lines, you should not even think of trying to turn the Data class, or your networked wrapper around Data, into a Singleton. Quite a few think this is a good idea. It isn't. Data is essentially a database table. Yes, you happen to need only a single table in this application. Now ask yourself, how many database-driven applications do you know that need only a single table? How much sense does it make to build this restriction into what is supposed to be reusable code? A Singleton here would be a grave architectural mistake.

- Peter
[ November 14, 2002: Message edited by: Peter den Haan ]

[Ramesh kumaar]

Thanks Peter
-rameshkumar

[Andreas Reuss]

Hi Peter,
I look forward to finish my project soon. I also have implemented Singleton pattern on Data, but in a way that ensures you only have one Data-instance for each file.
So you still can have more instances, but not reading/modifying the same file. Do you think this is bad design?
I did that because I think the synchronization on the Data methods is meaningless if you've got several objects accessing the same file.
Greetings
Andreas Reuss
[ November 16, 2002: Message edited by: Andreas Reuss ]

[Peter den Haan]

Originally posted by Andreas Reuss:
[...] I also have implemented Singleton pattern on Data, but in a way that ensures you only have one Data-instance for each file. [...] Do you think this is bad design?

Andreas, you answered your own question really. You encoded a fundamental constraint of the implementation -- fundamental, because things go horribly wrong when more than one copy of Data acts on a file -- into your architecture. This is entirely the right thing to do.
- Peter
[ November 16, 2002: Message edited by: Peter den Haan ]

[Trish Wu]

Sounds like a must for singleton with Data object.
But one thing i am not sure is that, how do u guys make sure each client can only unlock its own lock without keeping the state in the Data object and changing the lock and unlock method signature??

[Peter den Haan]

Only a "singleton" with small "s" and quote marks, because it's not an honest-to-GoF one-and-only-one-per-JVM Singleton.
As to your question, search this forum for "Connection" or "Connection object" and start reading
- Peter