aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Adapter pattern and DB interface Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Adapter pattern and DB interface" Watch "Adapter pattern and DB interface" New topic
Author

Adapter pattern and DB interface

Min Huang
Ranch Hand

Joined: Mar 17, 2004
Posts: 100
My instructions provide a DB interface and instruct me to name my data access class "Data.java" and have that class implement DB.
Is it still possible to use the Adapter pattern in this case? I am assuming DB is the Target interface, and Data is the Adapter. I would have another class, say Database, as the Adaptee. But then the Adaptee would be the data access class and would have to implement interface DB? Or am I not understanding the Adapter pattern correctly?
Thanks in advance for any help.


SCJP 1.4, SCJD 1.4, SCBCD (Preparing!)
Nathaniel Stoddard
Ranch Hand

Joined: May 29, 2003
Posts: 1258
The role of the adaptor is to adapt one interface to be compatible with another. In your case you would create a class DataAdaptor that would take some (more useful) methods. Those methods would dispatch their invocations to one or more invocations on the DB interface (the Data class).
Usually we would consider the class an adaptor if the "role" of the class is the same as that of the class being adapted to. A lightly related thinking would be to consider a particular class to contain (or use) the DB interface/Data class in carrying out whatever methods are invoked on itself.
While it's slightly confusing, the Adaptor pattern is especially useful when we want to decouple two classes: 1) some class using the Adaptor (which is now has a stable interface), and 2) the actual class the in-the-end does the work (the adaptee). That way, should the adaptee's interface change, the impact is localized to the Adaptor class, and does not propogate to the potentially many classes using the Adaptor.
What's your thought though? I didn't even consider the Adaptor pattern when I did the assignment. While it's useful to create more meaningful methods (i.e. bookRoom(), etc) in some control class, we wouldn't really consider those adaptors just because they use a class the main client never comes into contact with.
Make sense? Maybe if you could tell us more about what you're thinking we can be a bit more helpful, instead of rambling on about design patterns. Sorry.


Nathaniel Stodard<br />SCJP, SCJD, SCWCD, SCBCD, SCDJWS, ICAD, ICSD, ICED
Min Huang
Ranch Hand

Joined: Mar 17, 2004
Posts: 100
Thanks Nathaniel. As you confirmed, I do understand how the Adapter pattern works.
Here's what I was thinking: when I first read the assignment instructions, requiring the use of the DB interface, I got the idea that Sun was encouraging the use of the Adapter pattern so that the client would always have a standardized interface, no matter how the data access components change.
But I also realized that the Adapter interface doesn't have to be used, as long as the data access class is called Data and it implements DB.
My original difficulty was this: The major players in the Adapter pattern are the Client, Target, Adapter, Adaptee, and the Data (not to be confused with the class Data in Data.java). I was trying to figure out who's who.
Client => Client
Target => DB
Adapter => ? (Data?)
Adaptee => ? (Data?)
Data => database file
On one hand I am thinking: The data access class must be named Data. The Adaptee is the data access class, because it interacts with the database file. Therefore, the Adaptee is Data.
One the other hand, I am thinking: The Adapter must implement the Target interface (DB). Data must implement DB. Therefore, the Adapter is Data.
And then I got confused.
Now, I am thinking it's not possible to use the Adapter interface without getting a nasty autofail from Sun.
By the way, this is for the new URLyBird exam.
[ March 26, 2004: Message edited by: Min Huang ]
Bigwood Liu
Ranch Hand

Joined: Feb 26, 2003
Posts: 240
Hi,
I think you pay too much attention to the name of the pattern. Design pattern is used to facilitate and normalize programing, by using it, your program will be more maintainable. I do not think program is for pattern.
I think Data.java is just a implement of interface DB.java
Damu
[ March 26, 2004: Message edited by: damu liu ]
Min Huang
Ranch Hand

Joined: Mar 17, 2004
Posts: 100
Hi guys. After reading my instructions yet again, I am now thinking this: how about having the data access class called Data.java, and it implements the DB interface, and another class, DatabaseAdapter which uses Data. The DatabaseAdapter would expose only business methods like bookRecord(...) to the client, as I'm not sure why the client needs to know the low level details of interacting with the database, especially with locking/unlocking records.
However, there's just one thing that troubles me. Here's a quote from one of the comments in DB.java:

// Locks a record so that it can only be updated or deleted by this client.
// Returned value is a cookie that must be used when the record is unlocked,
// updated, or deleted. If the specified record is already locked by a different
// client, the current thread gives up the CPU and consumes no CPU cycles until
// the record is unlocked.

That comment seems to suggest that the client DOES have business knowing low level database details! Although, if I have an Adapter the client uses to communicate with the database, can I interpret that to mean the client locks the record, through my Adapter?
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi Min,
Originally posted by Min Huang:
Here's what I was thinking: when I first read the assignment instructions, requiring the use of the DB interface, I got the idea that Sun was encouraging the use of the Adapter pattern so that the client would always have a standardized interface, no matter how the data access components change.
But I also realized that the Adapter interface doesn't have to be used, as long as the data access class is called Data and it implements DB.
My original difficulty was this: The major players in the Adapter pattern are the Client, Target, Adapter, Adaptee, and the Data (not to be confused with the class Data in Data.java). I was trying to figure out who's who.
Client => Client
Target => DB
Adapter => ? (Data?)
Adaptee => ? (Data?)
Data => database file
On one hand I am thinking: The data access class must be named Data. The Adaptee is the data access class, because it interacts with the database file. Therefore, the Adaptee is Data.
One the other hand, I am thinking: The Adapter must implement the Target interface (DB). Data must implement DB. Therefore, the Adapter is Data.
And then I got confused.
Now, I am thinking it's not possible to use the Adapter interface without getting a nasty autofail from Sun.
By the way, this is for the new URLyBird exam.

I think it's perfectly appropriate to use the object adapter design pattern. In this case I think the participants would be as follows:
Target -> new interface
Adaptee -> Sun interface
Adaptee implementation -> Data class
Adapter -> adapter class containing an instance of the adaptee implementation, that delegates calls of the target interface to the instance of the adaptee implementation


Regards, George
SCJP, SCJD, SCWCD, SCBCD
Min Huang
Ranch Hand

Joined: Mar 17, 2004
Posts: 100
Hi George.
I read that thread with the huge debate about whether or not DB should be the interface exposed to the client. I considered your suggestion before, but I decided finally, out of a very paranoid fear of autofailure, that it should be the case that DB is exposed to the client (and not some other interface, even if it has the same methods, yes, I'm so very paranoid).
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Adapter pattern and DB interface