• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

NX: (B&S Contractors) Encapsulation Design Issues.

Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
I started my assignment with the data base implementation. So far I completed the 'DBAccess' interface and the corresponding 'Data' class. The DBAccess has methods for locking, unlocking in addition to other db functions and their signtaure is provided by SUN and I do not want to change it. Hence, the client GUI will have to call the functions in the following order to ensure thread safety.
db function(e.g. add)
However, I do not like the idea of making the lock, and unlock as public methods and also do not want to assume that client will follow this protocol. I want to provide an additional variation (or layer) of the interface where I would provide db functions that will take care of locking. I also created a class for handing a single record. I would also like to provide further encapsulation in this layer so that I can handle a 'record' object instead instead of String[] which is required in the signature of DBAccess methods.
However, since I am a novice at OOD, I am not sure what is the best approach for this. Presently my idea is to provide the following:
a. New Interface BetterDBAccess(no relation to the DBAccess)
b. New Class BetterDBAccessImpl which implements the new interface
c. The BetterDBAccessImpl class will 'contain' a object of the 'Data' class and will provide methods which will take care of threads and additional encapsulation.
I would like to know if this the right approach, potential pitfalls and if there is a better way of doing this.
Thanks for you help.
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Raj,
It sounds like you're exactly on the right track. What you're suggesting in a, b, and c, is an implementation of the object adapter design pattern, wherein you are adapting the BetterDBAccess interface to the Sun-supplied DBAccess interface (as implemented by the Data class). This is definitely along the lines of what many others on the forum have done. Something to consider while you are designing the BetterDBAccess interface is your network communications solution. If you go with the RMI solution, then that has some implications for how you should design your BetterDBAccess interface.
Hope this helps,
[ February 05, 2004: Message edited by: George Marinkovich ]
Raj Shekhar
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks George. Since, I do not have much experience with OOD, it is reassuring to know that I am on the right track.
Thanks also for the warning regarding the furure implications of a RMI solution.
permaculture is a more symbiotic relationship with nature so I can be even lazier. Read tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic