aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Singleton or static? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Singleton or static?" Watch "Singleton or static?" New topic
Author

Singleton or static?

xiaoma wang
Ranch Hand

Joined: Mar 04, 2002
Posts: 74
hi,everybody:
Either singleton or static variable seems to work well in some situation. But which is better? I mean, complying with the oo design principle?
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
Hmmm...I'm not really sure about the context of this question, but this is my basic guideline for when to use each one.
Using a singleton enforces the rule that you can only ever have one instance of a class. This implies that you need an instance of that class in order to accomplish your goal.
However, if you don't need an instance of a class in order for that class to do its job, using a static member(s) would probably prove to be a simpler solution.
If you give me a little more idea of what you're trying to do, maybe I can be a little more help.
Corey


SCJP Tipline, etc.
xiaoma wang
Ranch Hand

Joined: Mar 04, 2002
Posts: 74
hi, thanks Corel:
In my scjd design, when the client connect to the rmi server, every client will obtain a specific remote object instance, which contains "database" instance, for its own connection. I'd like to make all the clients to connect to the same backend "database" instance contained in the remote object instance. Now I choose the "database" instance as a static variable and it work fine. But, maybe singleton is better? I really don't know..
Thanks in advance, Corel!
xiaoma wang
Ranch Hand

Joined: Mar 04, 2002
Posts: 74
Sorry, thanks Corey, not Corel!
xiaoma wang
Ranch Hand

Joined: Mar 04, 2002
Posts: 74
Sorry, thanks Corey, not Corel!
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

xiaoma -
First Javaranch has a policy that you must register with both your first and last names.
2nd, I would suggest neither Singleton or Static. I would suggest that when you create a new instance of your connection object you pass a reference to the data object to it's constructor. Now every client will have it's own reference to the same Data object.
Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
xiaoma wang
Ranch Hand

Joined: Mar 04, 2002
Posts: 74
hi Mark, I get you. Thanks very much!
Xiaoma Wang
Nico Vanoppen
Greenhorn

Joined: Mar 22, 2002
Posts: 12
Hi there,
Maybe I don't understand your problem but when you are using RMI, don't all the clients get a reference to ONE SAME OBJECT, namely the one that your server registered with the RMI-registry ? If so, your problem doesn't exist, does it ?
best regards,
Nico
xiaoma wang
Ranch Hand

Joined: Mar 04, 2002
Posts: 74
hi, Nico:
When I connected to rmi, every client get its own connction object and all the connection object instance contains the same data object. That is what i want. And Mark's suggestion is perfect!
Xiaoma Wang
Nico Vanoppen
Greenhorn

Joined: Mar 22, 2002
Posts: 12
Hi there,
Sorry, but you've lost me. I'm also working on the SCJD exercice and I approached that problem like this : let the server instantiate the Data class just once and register this object with the rmi-registry. Clients requesting the Data object all receive a remote interface whose methods "invoke" the methods of this one object. I don't understand the need of "connection objects" to solve this problem.
Greetings
Nico
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

Nico, one of the requirements for the Server was an interface that implements all the public methods of the Data class. What this really does, besides make it nice to switch between local and remote mode. It also de-couples the Data class from everything. the data class know nothing except how to read/write/modify the db.db file.
So by binding the Data class into RMI, you have to rely more on that Data class to handle more things. First you have to change the signatures of all the methods, and also have it extend UnicastRemote. Not really a good design there.
What xiaoma is doing is taking a factory class called ConnectionFactory and it has a reference to the one and only instance of the Data class. It also has a method called getConnection(). This method creates a Remote object that resides on the server machine, and has a one to one relationship with the clients. Each client has it's own Connection object to service it's needs. When the getConnection method creates this class it passes a reference to the Data object via it's constructor.
Mark
Nico Vanoppen
Greenhorn

Joined: Mar 22, 2002
Posts: 12
Mark,

So by binding the Data class into RMI, you have to rely more on that Data class to handle more things. First you have to change the signatures of all the methods, and also have it extend UnicastRemote. Not really a good design there.

Can you give me an example of one of those more things that the Data class must take care of when using my idea of design because I can't bring one to mind.
I suppose that it's for these extra tasks you would alter the signature of de Data class
Ain't extending the UnicastRemoteObject sexy enough
Nico
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

First the client will need to know full knowledge of the Data class, because that is what it is receiving. So any changes to the Data class needs to consider any changes that will need to be done on the client. Whereas, if you have a connection class, then the underlying Data class implementation is hidden, and therefore the client doesn't need to know that there have been underliying changes to the Data class.
Meaning, if you were to change the Data implementation to use an actual Database rather than db.db, you could make those changes. It is the old black box, encapsulation of OOP that needs to be considered.
Mark
Nico Vanoppen
Greenhorn

Joined: Mar 22, 2002
Posts: 12
Mark, thanks for explaining.
I also have thought about this but reasoned that since the client deals with the remote INTERFACE of the Data class we could change it's implementation without altering client code. If your implementation changes mean also changing the interface, then ofcourse changing the client code is necessary. But I suppose using a real database instead of db.db won't do this, will it ?
Thanks,
Nico
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

But I suppose using a real database instead of db.db won't do this, will it ?

do what? I mean your design is such that it actually emphasis the ease of changing the database. That is the benefit of decoupling, it allows for extensibility, maintainability, and all the other ilities.
Mark
 
 
subject: Singleton or static?