In my design the DBMain implementor has default access as you said. In the suncertify.db package I also created a DBMainFactory class which is a singleton that has a public method that returns a DBMain object based on a parameter that is provided by it's clients.
My business interface is in the suncertify.business package and retrieves the DBMain object via the DBMainFactory class.
Hi Jar, I didn't think that I would get that lucky and have you personally answer my question , so thanks for the reply since we are at it I have to say that you design is really interesting and BIG congratulations for the great grade that you got. I think i will have more questions soon since my next step would be RMI.
I want to hide the locking methods by adding an adapter. If this adapter is in a different package (suncertify.business as you named it) then I am still not hiding the locking methods.
am I going to the extream with hiding the locking methods? there is another way to handle locking record (without hiding locking methods) that requires MENTIONING the sequnce of doing things in the contract ( for example lock update unlock).
I think there is no need to try to hide the lock/unlock methods on the database layer, after all they are part of the public DB interface.
It's the business's Adapter class who will be hiding this methods to the GUI.
About the sequence of doing things (lock-update-unlock) I didn't mention it in my DB interface Javadoc comments but I did force this use in my DB interface implementation class by validating in the update and the delete methods that the record to modify is effectively locked. If it isn't locked I throw an exception:
My DBException is wrapped in a DBRuntimeException as the DB interface does not provide a nice exception treatment. My business adapter can then recreate the original DBException from the enclosing DBRuntimeException.
Jar [ August 30, 2007: Message edited by: Jar Jaquiso ]