What is everyone's opinion on wrapping the Data class in a Singleton? What I have in mind is implementing lock, unlock and criteriaFind in the Singleton and the only modification that I make to the Data class is fix the deprecated methods. I would have two different Singleton classes (one for remote and one for local). I would return the appropriate Singleton based on a previously set property using lazy instantiation in a static getInstance() method. My DataAccess (and RemoteDataAccess) implemation class would interact with the Singleton.
I appreciate everyone's opinion
And, please justify your choice of Singleton
And, please justify your choice of Singleton
Am I missing something here? How can there be more than one instance of Data and protect the ONE database file?
Well, the main problem is "performance". When a lot of clients do such "reading functions" as criteriaFind(), they are accessing the same one thread, thus may result in bad performance
Only one thread can go at a time anyway because I am synchronizing the criteriaFind() method (which calls other synchronzied methods of the Data class).
I'm not sure you understand what I'm proposing. There will be multiple client threads accessing the Singleton (which is essentially a proxy for the Data class). The remote Singleton also will manage all locking behavior, ie create a lock manager, verify that a record is locked before allowing modification, etc.
In short, a disastrous idea. I have seen Singleton mentioned as the single most often abused design pattern, and from my own observation this is patently true. Most Singletons are bad mistakes, poor OO design, and this is a prime example.
Originally posted by Michael Morris:
What is everyone's opinion on wrapping the Data class in a Singleton?
Disastrous? Mistake? Poor design? Surely everyone can't be wrong?
Creational patterns such as the Singleton should be used to encode fundamental properties and assumptions in your problem. The fact that you happen to need only a single copy of Data is not at all a reason to use the Singleton pattern. The question is, is there a fundamental reason why you can have only a single copy, both right now and in future revisions of the software?
Well, no. To the contrary.
Data represents a single database table. In years of developing databases, I have encountered only one (1) database with only a single table. That was the Fly By Night database. Every other database had at least two or three tables. If you want to write the database server code for re-use -- as you are asked to do! -- you cannot assume there will be only one data file and only one Data instance. Casting this assumption in concrete by employing the Singleton pattern would represent a deep and fundamental flaw in your design.
Now if you would devise a creational pattern that would enforce a single Data instance per data file, things would be altogether different.
[ April 09, 2002: Message edited by: Peter den Haan ]
Thanks for the opinion. Consider the Singleton gone. I was uneasy about it anyway, hence the post. I guess now my problem is how do I best encapsulate the Data object. Do I instatiate it in my Connection Factory and pass a reference to the DataAccessImpl objects? Do I start it up in the server?
It was a good explanation. I am still going to use Singleton but not in the Data class but in the sub classes of Data. Each sub class corresponds to one table and therefore one Data(sub class) instance.
I don't see anything wrong in using Singleton for sub classes of Data.
Consider something likeI'm not saying you should use this code as listed above. It all depends on your design and there are some loose ends too. I just wrote it to illustrate how you could implement a "per-file-singleton" creational pattern. This would be a good creational pattern to use, because there are very fundamental reasons why it is not safe to instantiate more than one Data object for one and the same file.
A more sophisticated version would use lock files to enforce the single-Data-per-file restriction even when the Data objects live in different JVMs (for example, the server is started twice).
Again I'm not saying you should do this (in fact I didn't personally) -- you may decide to leave it up to the programmer to ensure that there won't be more than one Data talking to a given file. This is one of those design issues that you need to think about, decide upon, and document.
PS. The DataFactory should be a full-blown Singleton, though; I'll leave that as an exercise for the reader
[ April 10, 2002: Message edited by: Peter den Haan ]
I thought about this Factory to create Data instances. Like you said, the programmer needs to make sure he/she doesn't instantiate the Data instance directly.
Below are my justifications to create a sub classes of Data:
1) Constructors of Data have "protected" modifiers. So no one can create an instance of Data except the sub class instance.
2) criteriaFind() method in the spec needs to do wild-card like search for origin and destination if the user enters "any" for one or both of them.
In the criteriaFind() implementation, I use template pattern to let the sub class decide if the values typed in the screen and read from the table are equal or not. I can forsee more requirement like this for not only this table but other tables.
Make sense? Your comments please.