Adapter pattern

[Rob van Oostveen]

Fellow ranchers,

I received the URLyBird 1.2.1 assignment recently. I'm considering the Adapter pattern for Data objects. Let me be more specific;

Data class implements DBAccess and is wrapped in an adapter class. Every client thread in the server application will create it's own adapter object. The Data object will be passed to each new adapter object. This way, only one instance of the Data object will exist. The adapter class will have a small number of some specific methods.

Is this a correct implementation of the adapter pattern?

Please let me know your thoughts.

Thank you.

Cheers.
RvO

[Edisandro Bessa]

Hi Rob,

I think you are confusing the Adapter Pattern with the Composition Pattern.

I think everything you said above is better applied to the Composition Pattern once you have a scenario where one class wrappers another class to add some functionality. (If I did not misunderstand you of course!)

Think about the java.io classes : BufferedWriter takes in its constructor a FileWriter which in turn takes in its constructor a File class.

BufferedWriter = new BufferedWriter(new FileWriter(new File("myfile.txt")));

If you have in your app the scenario I explained above, for sure you are using the Composition Pattern instead of Adapter Pattern.

On the other hand, the Adapter Pattern is for those situations where you want to convert a class reference for another class type expected by your program and that is not on the same class hierarchy of the class being converted.

This pattern does not add functionality at all. It only changes some class interface to another identical interface always maintaing the same functionalities.

Example :

Supposing you have the following class

class Duck{
    public void quack() { System.out.print("I'm quacking");}
}
 
and you want to convert to another type of Duck your program expects, say a Brazilian Duck
 
class BrazilianDuckAdapter{
    private Duck generalDuck;
    
    BrazilianDuckAdapter(Duck duck){generalDuck = duck;}
 
    [B]// Another different way of quack. But still quacking...[/B]
    public void scream(){
        generalDuck.quack();
        generalDuck.quack();
        generalDuck.quack();
        generalDuck.quack();
    }
 
    [B]// Note that no functionality was added. We just adapted
    // the way this Duck quacks[/B]

Sometimes we can get confused with the Composition Pattern because of the wrapped properties needed to implement the Adapter class, in this case the private generalDuck property. But the key point here is : No functionality was added.

Did you get the point ?

I think anyone else can give us a better explanation but I think I'm on the right track.

Best Regards.
[ September 05, 2006: Message edited by: Edisandro Bessa ]

[Rob van Oostveen]

Edisandro,

Thank you for your answer. I think I understand what you are saying. And in my opinion I am not adding functionality, I'm just simplifying it. Here's an example of what I'm trying to do;

 
// Sample/partial interface declaration
interface DBAccess {
 
  public String[] readRecord( ... );
  public void updateRecord( ... );
  public long lockRecord( ... );
  public void unlock( ... );
 
}
 
// Sample/partial implementation of DBAccess
class Data implements DBAccess {
 
  public String[] readRecord( ... ) { ... };
  public void updateRecord( ... ) { ... };
  public long lockRecord( ... ) { ... };
  public void unlock( ... ) { ... };
 
}  
 
/**
* Point here is that the adapter delivers the same
* functionality as Data but simplifies the interface by 
* reducing the available public methods and the 
* recordlocking plus synchronization is handled by the 
* Data class. This way the client doesn't have to worry
* about locking and synchronizing.
*/
class AdapterData {
 
  Data data;
 
  public AdapterData( Data d ) { 
  
  data = d;
 
  };
 
  // ...yes, i know, one can debate about locking a record when 
  // you only want to read it... but that's another discussion.   :)  
  public String[] readRecord( ... ) {
    ..
    cookie = data.lockRecord( ... );
    recdata = data.readRecord( ... );
    data.unlock( ... );
    ..
  };
 
  public void updateRecord( ... ) { 
    ..    
    cookie = data.lockRecord( ... );
    data.updateRecord ( ... );
    data.unlock( ... );
    ..
 
  };
 
} 
 
  ..
 
  // Instantiate Data object only once 
  Data d = new Data();
 
  ..
 
  // When new client thread is started
  // Instantiating new Adapter for use in the new client thread
  AdapterData ad = new AdapterData( d );
  

And if I'm correct. It's even better to have an interface defining
how to implement the AdapterData class. This way the class can be
substituted by another whenever the database source changes in the
future as long as the new AdapterData class implements the interface.

Best regards,

Rob
[ September 05, 2006: Message edited by: Rob van Oostveen ]

[Rob van Oostveen]

I'd like to add that the new AdapterData object holds the client cookie as well. And is used by the methods who need the client cookie.

This doesn't change functionality in my opinion.

Regards,

Rob
[ September 05, 2006: Message edited by: Rob van Oostveen ]

[Oricio Ocle]

Hello,
Adapter pattern is also known as Wrapper (@see GOF).

But IMO there is a slight difference:
- Adapting suposes have in mind a fixed client interface that must be implemented. Clients already exist.

- In wrapping: Clients dont exist yet. You are not restricted to a fixed interface.

Once you see the overall design is difficult or even imposible to distinguish between them. The difference is in the analisis process, not in the result...

That is how i understand both.

So in your case i would name it "wrapper" not "adapter"

On the other hand... i dont know any composition pattern...
Are you,Edisandro, refearing to composite pattern?

Regards
[ September 06, 2006: Message edited by: Oricio Ocle ]

[Edisandro Bessa]

Some authors give different names to the same things.

In my explanation the Composition Patterns would be considered as a kind of Wrapper Pattern.
[ September 06, 2006: Message edited by: Edisandro Bessa ]