Singleton question
I have an existing object DataManager that gets passed to many other classes' constructors because those classes need a reference to this object. Now, understand that I never need to instantiate more than 1 object of type DataManager during a run of the system. So, I'm thinking that DataManager qualifies as a singleton because all I need is the single reference. But here's the catch: DataManager has many methods that should only be called after data is read into this object because the other methods presuppose that the data has already been read in. I'll call these other methods "post ingest methods" for simplicity. Is there a good way of passing references to DataManager around to other objects without having to worry about the class users calling the "post ingest methods" before the data has been read in? Perhaps the Singleton pattern doesn't fit in this case but I thought it was an interesting idea. Thanks for any input.
I guess to elaborate on my question, I'm interested in applying the Singleton pattern to my design but I would like the getInstance() method to return a loaded (file data already read in) object. Of course, the data only needs to be read into the object in one place in my code but other classes need to have a reference to the singleton so they can ask it to perform different operations. So I thought about modifying getInstace() so that it includes a File parameter: getInstance(File data). That way, when the instance is requested, it will be guaranteed to contain the necessary data. The drawback to this approach is that other classes that are only interested in the services offered by DataManager (and not the data ingesting process) would need to pass in a File parameter and that doesn't seem like a good design.
Actually, I'm not concerned with whether or not your object is a singleton. This is really unrelated.
I am assuming that your DataManager is aware of whether or not data has been read into it yet.
In the jargon, we say that it is a "pre-condition" of your methods that the data should be read into your object. You should check for this condition before you execute the method. If the condition fails, you should throw an exception (the appropriate exception here would be [url=http://java.sun.com/j2se/1.5.0/docs/api/java/lang/IllegalStateException.html]IllegalStateException[/url]. This is a runtime exception, so you don't need to declare it, but you should javadoc it. Then, let the classes that call those methods handle the exceptions as they need to. You should do this whether your object is a singleton or not.
- Adam
> But here's the catch: DataManager has> many methods that should only be called after data is> read into this object...That suggests that it isn't an object in the OO design sense.
> That suggests that it isn't an object in the OO> design sense.Sure it is, it's a "God Object": http://en.wikipedia.org/wiki/God_object
> > That suggests that it isn't an object in the OO> > design sense.> > Sure it is, it's a "God Object":> Probably but I didn't want to confuse the issue by introducing an anti-pattern.
> > > That suggests that it isn't an object in the OO
> > > design sense.
> >
> > Sure it is, it's a "God Object":
> >
>
> Probably but I didn't want to confuse the issue by
> introducing an anti-pattern.
Ok, now that the God class topic was brought up, I need some input on this issue. I just read the wiki article on God classes and I'm sure my DataManager class shows some signs of being "God-like," but I'm not so sure there is any other way to implement the design. My DataManager at the very least needs to be a container for a potentially large chunk of data that is unmarshalled from an xml file using JAXB. Now, according to the wiki entry, a "God object is referenced by so much of the other code." I'm wondering, how can this possibly be avoided in my case? Of course the DataManager will be referenced by other classes a lot. How else are they going to obtain the data? Sure, my other classes could read the data from the file each time the data is needed but that would become blatently unacceptable. Any ideas?
I'd ditch the DataManager and look into the DAO pattern. %
> I'd ditch the DataManager and look into the DAO
> pattern.
>
> %
That seemed like an interesting idea but after reading a little about it, it seems that using a factory pattern (given the fact that I only use one data source, i.e. an XML file) I don't see how a factory would be any different than a singleton, which gets back to my original post in this thread.
> How else are they going to
> obtain the data? Sure, my other classes could read
> the data from the file each time the data is needed
No one suggested that.
> but that would become blatently unacceptable. Any
> ideas?
You have one object. You need more than one. How that exists depends on specifically what the data is.
The purpose of a singleton is not that you only need one of it. The purpose of a singleton is to ensure that there can only ever be one of it.Your statement in the first post does not indicate any need for a singleton.
It's implicit that there should only be one DataManager - every object would acess data through the same object.
the interesting bit here is that Spring objects are singletons by default. the reason DI works for DAOs is that you start with an interface and write implementations that have no state and can be shared, like stateless session beans.
if you write the object that way, you can have a singleton. it can even be clustered, because there's no state to replicate on different instances.
maybe it can work...
i still think DAOs and DI would be a sounder basis for this. I'm betting that the DataManager has state, making it harder to share safely. (Requires synchronization, which means it's slower and becomes a bottleneck.)
Don't mind me - just rambling before that plunging into a work assignment.
%
Well, I appreciate the replies to this Thread since I really would like to find a decent solution to my problem. Unfortunately, I suppose I can't accurately convey the problem in a concise enough manner for you guys to give me appropriate advice (given the responses) without offering a complete case study. I suppose I'm making the issue sound like a database issue when it's not even remotely related. I'll keep trying to find a decent solution. Thanks again.
I don't even see how you think a singleton addresses your concern? You seem to have a lifecycle concern over which object instantiates which. I agree that some form of dependency injection is in order.
Objects sould not have access to uninitialized objects unless they are responsible for that objects initialization.
You are right. It's not obvious to us, for example, why these "post-ingest" functions are methods of your global object DataManager, instead of being methods of the objects that it produces.
Take JDBC, for example. It has a Connection object that you can use to extract data from a database. But once the data is extracted, you don't call Connection methods to process the data, or any JDBC methods at all. The data is now autonomous and you use its own methods to process it. Somebody (duffymo?) mentioned the DAO pattern, which that's roughly what it is.
Try this: suppose you have a new boss who is a fanatic. You have been ordered to get rid of the DataManager entirely. What would you do? You already know why it should exist; now go and find reasons why it shouldn't exist, or what should happen if it doesn't exist.
