Hi I got the basic design laied out. But for some reasons I feel this is not ok. Can some one comment on this ? I have an interface called DatabaseIntFace which has all the public methods of Data class. I have classes called RemoteServer and LocalServer for remote and local modes. These two classes implements DatabaseIntFace. Within the RemoteServer and LocalServer I have Data object as a member. I will be instantiating Remoteserver or LocalServer based on the users input and creating an object called database. From RemoteServer and LocalServer I will be callig data.methods( ). The reason I did this is to hide the Data class for the clients. Also make Data class common for Local mode and Remote mode. Any code which is specific to Remote mode would be in RemoteServer and similary local code in LocalServer. Do you people see any problem with this approach ? Also I am not sure what type of pattrens I can implement here excepting I can implement factory pattren to create database object. Your comments will be appriciated. [This message has been edited by Raju, Gentle (edited September 25, 2001).]
My basic design is roughly the same apart from that I use an abstract classes to blueprint the public methods of Data.class. The server in my design must always be available as that instantiates the database. I have a remote and local wrapper that mimic the methods of class Data. The Gui doesn't handle the remote/local issue as this is given at start up via the commandline.
posted 18 years ago
Hi Good to know that some one there thinks the same way. What is the advantage of having abstract class here and where do you place this abstract class ? [This message has been edited by Raju, Gentle (edited September 25, 2001).]
posted 18 years ago
I have created a util package that contains the abstract class and a few other things like logging and unit test classes. I used an abstract class because I can reuse the same class, if I use RMI, sockets, COBRA. I am leaning towards using sockets as it is not a proprity solution and can be adapted for the internet easier than RMI.
What I am doing is creating a trivial version of JDBC. You may have a ConnectionManager that's ,like you mentioned, an object factory, a Connection interface, possibly AbstractConnection class to implement common funtions and then RMIConnection, SocketConnection or FileConnection concrete classes. It makes sense to me. Essentially, we are doing the same thing and JDBC is a perfect blueprint.
This tiny ad is suggesting that maybe she should go play in traffic.
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop