Hi all, I am having I design problem, and it�s as following.
In implementing Data class I needed public methods not found in DB interface, and that's create maintainability problem if I want in the future to replace the Data class, I can continue my work with the following Decisions:
1-Let the other objects communicate with Data class interface not DB. Data data = new Data(); Not DB data = new Data(); ant that's creates a problem with maintainability, some of the classes will depend on my new public methods.
2- Create an Interface extends DB interface (DBExtended) and let Data implements DBExtended, by that I don�t think I am breaking the rule "must implement DB interface" because by implementing DBExtended I am implementing DB (not sure) .
3- Remove the public methods, witch will effect my whole design and remove many of the good thing about it.
4- using an Adapter class, and this choice can't be done, because some of public methods I need, has to communicate directly with data file, such us getSchema().
as I see it the second choice is best one, but the MUST word makes me hesitates.
any second Opinion. [ June 10, 2004: Message edited by: Omar Kalaldeh ]
Best Regards <br /> <br />Omar F. Kalaldah<br />---------------------<br />SCJP, SCJD, SCBCD
With option 2, your data class will still meet the rule that it implements the interface.
Alternatively you might want to consider what it is that the Data class provides, and then decide whether your other methods truly belong in the Data class. You may find that it may make more sense to move your extra methods to some other class which your server and standalone client can call.