• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Javini's Design

 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
This is my current design. Here are my major "risky" decisions of which I
am checking:
1. Data must implement DBMain interface. I have declared Data abstract
and all its methods. Is this okay?
Well, that's my only question that I'm worried about. Here is the design
which gives things their context:


In short, I don't alter DBMain and Data, though I do make Data and all its
methods abstract.
The factory is not shown, but the user can use the factory in two ways:
For hard-core, non-internet interested people, they can use the factory
to get back a DBMain interface reference which is an instantiation of MyData.
There would be no need for the client to call lock() and unlock() unless the
client decided to multi-thread (which I may dis-allow in the comments).
DBMain and DBMain2 have the same method names. DBMain2 functions to link
MyData to DataImpl. The point is that the factory also returns, at the
request of the user, a VersatileDataInterface which will either be the
instantiation of MyData or DataImpl.
The client using VersatileDataInterface writes code which has to be prepared
to handle remote exceptions, but the actual type could be the local MyData
or the remote DataImpl.
DataImpl simply forwards calls to MyData, while taking into account logical
record locking.
I have AbstractData used in case I want to change the implementation of MyData,
such as creating a new class someday called MyNewData. But, I may end up taking
AbstractData out of the design for the submittal.
In short, the server exposes "Data" to the client.
Thanks,
Javini Javono
[ February 24, 2004: Message edited by: Javini Javono ]
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Javini,
The fact that the assignment instructions are very explicit that the Data class implement the Sun-supplied database interface indicates to me that the examiner may want to perform some unit tests on the Data class directly. That is, he may expect to be able to instantiate the Data class and then run tests of the database operations: create, read, find, delete, lock, unlock, isLocked, etc. If your design allows the Data class to be instantiated and tested in this way then I think you're fine. If your design makes this difficult for the examiner then I think it's probably a mistake.
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
George, thanks for your advice. I keep forgetting this is not the real world,
and there is no customer around to confer with. Given this, no need to get
fancy, and I will work with Data directly.
Also, I will follow your advice I saw in another thread, wherein Data always
implements the lock() and unlock() methods because it doesn't add that much
overhead to local, stand-alone mode to worry about it.
Here is the new design diagram with comments:
I've essentially gotten rid of any non-essentials, with upon your advice George,
starts to ring true to my ears:

In short, I don't alter DBMain, but Data will be an instantiatable class so
that, if required, the Examiner may instantiate it (also, as George pointed out,
the directions do say that Data must implement DBMain, so I will not do anything
fancy and argue that a class extending Data "is a" Data).
The factory is not shown, but the user can use the factory in two ways:
For hard-core, non-internet interested people, they can use the factory
to get back a DBMain interface reference which is an instantiation of Data.
There would be no need for the client to call lock() and unlock() unless the
client decided to multi-thread (which I may dis-allow in the comments). As
George pointed out in another post, to leave in the locking code is no big cost:
the client can decide whether or not to use the locking when in local mode.
Plus, by not forcing the user to not use locking, the blocks of code
the user writes can easily be adapted to the VersatileDataInterface.
DBMain and DBMain2 have the same method names. DBMain2 functions to link
Data to DataImpl. The point is that the factory also returns, at the
request of the user, a VersatileDataInterface which will either be the
instantiation of Data or DataImpl.
The client using VersatileDataInterface writes code which has to be prepared
to handle remote exceptions, but the actual instantiated type could be the local
Data or the remote DataImpl.
DataImpl simply forwards calls to MyData, while taking into account logical
record locking. (But, this comment may be revised if Data also takes into
account record locking)
In short, the server exposes "Data" to the client.
Thanks again, George.
Javini Javono
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic