• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Design for FBN.Pls review

 
Akshay Sharma
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On the server side
I have a Connection Factory which basically gives
instances of a FlightDAO object which in turn implements FBN remote interface and Unreferenced.
Then I have a DataWrapper class which is a singleton and creates a data instance within itself.
FlighDAO has a DataWrapper instance with it.
LockManager takes care of locking and tracking clients. Lock and unlock are implemented in Data only.
On the client side I have a ModeFactory wehich determines the Mode in which the app will execute.
In case of RMI we get an instance from the factory.
In case of standalone mode, I have created a Standalonedao WHICH extends FlightDAO thus resusing the already existing class.
For client deaths etc I have implemented Unreferenced.

Also I have just a array of in in the FlightDAO where I store the records locked by a particular instance.
In unreferenced I call Data unlock to unlock all owned locks.
While unlocking I first check whether the record num is a part of owned locks
Plsd review
[ July 25, 2003: Message edited by: Akshay Sharma ]
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11866
194
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Akshay
Looks good.
Why have you made your DataWrapper class a Singleton? Not that this is necessarily wrong, but just wondering what your reasoning is.
Regards, Andrew
 
Akshay Sharma
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Data Wrapper is just a Wrapper over the Data class and
it makes sure that I dont create multiple instances of Data class
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11866
194
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Akshay
I am not disagreeing with this, but just to give you something more to think about ...
One topic that is often discussed here is what are potential enhancements to the system, and how should we cater for them?
Making this class a Singleton ensures that there can only be one instance of the DataWrapper class, now and in the future.
If a later requirement was to have a secondary table (for example, storing customer records), there would have to be some rewritting of your code to handle the extra table.
Whereas if you allowed mutiple instances of the DataWrapper class to exist, but only used one instance of the DataWrapper class, then other classes could be written which could use a different instance of the DataWrapper class for a different table.
You have to decide whether there is any value in catering for this future potential or not.
The major argument against it is that you dont need it now, and who knows what the future requirement may be (which may require the code to be rewritten anyway). Or put another way: You Aren't Gunna Need It.
Regards, Andrew
 
Akshay Sharma
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Point taken sir.
What if I make it a multiton in the sense that
For a table/file type we will ensure that we should
be able to create only one instance.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11866
194
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Akshay
That sounds like a very good way of handling the issue.
Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic