Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Adapter or not Adapter ???

 
Tony Collins
Ranch Hand
Posts: 435
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One thing has been bugging me about my design, is the Adapter Pattern.
I think I have three Adapers.
1) a DBAdapter to Adapt Data which uses lock, unlock etc to produce an interface containing bookRecord, getRecords, getColumnNames.
2) An Adapter LocalClientAdapter which adapts DBAdapter to provide functionality for Local access to the DB.
3) The same as 2 but for remote access.
I'm confused as 1) really does alot of work it calls methods in order etc etc. So is that an Adapter.
And 2 and 3 really just either handle or throw caught exceptions are they adapters.
And if they are all Adapters whats the difference between an Adapter and a wrapper
Tony
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tony,
And 2 and 3 really just either handle or throw caught exceptions are they adapters

All of the cleasses you mentioned are adapters. Adapter is the class/interface whose main purpose is wrap another class to change his methods signature. Whether it is new exception to be thrown or new method it doesn't matter.
And if they are all Adapters whats the difference between an Adapter and a wrapper

Wrapper is (to my opinion) more more common notion. It has no the main purpose to change interface. Example: Integer/Long and son are all wrappers, but not adapters. They wrap int/long.

One question: Is your adapter #3 on the client? If so, why do you need it for?
I have
- one ServerAdapter class on the server to change change signature of methods
- one RemoteServerAdapter class on the server with RemoteExceptions
- one adapter on the client ClientAdapter , adopting/wrapping RemoteServerAdapter to hide RemoteException.
The Factory class on the client gets either ServerAdapter object or RemoteServerAdapter. In case of RemoteServerAdapter is will be wrapped in ClientAdapter. So Factory delivers either ServerAdapter or ClientAdapter class. Both of them implement the same interface. So, the client GUI actually doesn't know if it is local or remote mode.

By the way, nobody , who hides lock/unlock/readRecord/delete/create/update methods in the Adapter class doesn't worry about following requirement:

The following are the "top level" features that must be implemented:
A client program with a graphical user interface that connects to the database
A data access system that provides record locking and a flexible search mechanism
Network server functionality for the database system

Only Adapter classes (book, find, getSchema) in our case will be available remotely. I am afraid it is dangerous.
Andrew said, well just put other methods in interface. I don't think it is good idea to have interface containing methods together:
book (implicitely locks record):
update (doesn't locks record)
lock
unlock
read
find
I have sent the question to Sun whether it is Ok to make only three methods, needed by our client, available remotely. It was at least one month ago.
I have NOT got any answer !? ...
Best,
Vlad
[ September 16, 2003: Message edited by: Vlad Rabkin ]
[ September 16, 2003: Message edited by: Vlad Rabkin ]
 
Tony Collins
Ranch Hand
Posts: 435
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The differnece between the LocalAccess and RemoteAccess Adapters in my design is that the RemoteAccess Adapter will handle Exceptions on the Server side and the Local Adapter will pass these Exceptions up to the Client GUI.
I don't use an Adapter to mask out the remote Exceptions, locally they just will not be thrown.
Tony
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tony,
I am afraid I am not able to understand your design. Could you please tell exactly where is located each of your adapters on the GUI client, or on the database server.
For example, my design looks like this:
Server:
Interface: DB
Class: Data class
Interface: DBAdapter
Interface: RemoteDBAdapter extends DBAdapter, Remote
Client:
Class: ClientAdapter implements DBAdapter (wraps RemoteDBAdapter)
GUI are working always with DBAdapter Interface
Could you please send a message in the same format?
Best,
Vlad
 
Tony Collins
Ranch Hand
Posts: 435
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This might make it clearer.
Remote Mode

Controller ----> DBRemoteAccess ----->DBAdapter--->Data



Local
Controller ---> DBLocalAccess ----->DBAdapter--->Data

The difference between DBRemoteAccess and DBLocalAccess is that DBLocalAcess passes Exceptions to the Controller, where DBRemoteAccess logs and handles them.
Tony
[ September 16, 2003: Message edited by: Tony Collins ]
[ September 16, 2003: Message edited by: Tony Collins ]
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vlad,
Andrew said, well just put other methods in interface. I don't think it is good idea to have interface containing methods together:
book (implicitely locks record):
update (doesn't locks record)
lock
unlock
read
find


I don't think I ever advocated having all those methods available over the wire at the same time.
I can understand people having only book, find, and read methods available over the wire. With the lock method that does not return a cookie, it could be argued that the specification does not require the lock to be available to the client directly. Since I can understand that position, I don't argue against it. Especially as for a long time I appeared to be a lone voice against it.
However I don't really agree with it, as you will see if you can follow this convoluted logic:
With the lock method that does return a cookie, I don't think the cookie has any value at all unless it is intended to be used remotely.
So we have FBNS which required the locking to be done on the client side, and several versions of URLyBird and Bodgitt & Scarper that kind of make sense for the locking to be done client side.
So I think that probably Sun intended for all assignments to have locking done client side, but missed that they had left a loophole for people who want an easier task.
Anyway, if lock (and therefore update ...) are available on the client side, then there is no real need to have the book method server side.
If you did have book server side as well as lock and all the rest client side, then you would have to make sure that you could not call lock followed by book (or at least handle the problems that this could create).
Regards, Andrew
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tony,
The GOF book, lists Wrapper as another name for Adapter. They do not differentiate between the two patterns.
Regards, Andrew
 
Michael Fitzmaurice
Ranch Hand
Posts: 168
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tony
Depending on the main intent of the class you mention at 1.) in your original post, it sounds like it could also be regarded as an example of the Fa�ade pattern.
I say this because it would appear to be simplifying the interface to a particular subsystem or class (in this case your data access class) by providing only a subset of the original class functionality in its interface (i.e. it masks the complexity of using lock/unlock and exposes a more simple 'book' method in its API).
Its a grey area though - if the main intent is to make the data access class interface conform to an interface required client-side, then yes, its more of an adapter.
I am doing the contractor (Bodgitt & Scarper) assignment. The GUI instructions specify that the user should be able to search for (on name and/or location) and book contractors. No mention of add or delete, or lock/unlock. I regard my own equivalent server-side class as more of a fa�ade. I decided on the interface required client-side based on the GUI instructions and realised that the client had no need for any methods other than searchByName, searchByLocation, and bookContractor. The fa�ade class therefore exposes only these methods.
In the end though, what you call the pattern you are using (wrapper, adapter, fa�ade, whatever) is not really that important, so long as you can explain and justify it using principles of good OO design.
[ September 17, 2003: Message edited by: Michael Fitzmaurice ]
[ September 17, 2003: Message edited by: Michael Fitzmaurice ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic