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
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 - 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
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
posted 18 years ago
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
posted 18 years ago
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
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
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
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
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
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