• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Head First Design Patterns -- Chapter 7 - The Adapter Pattern - More than just change the interface?

 
Ranch Hand
Posts: 262
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I've been trying to understand the Adapter pattern for sometime now. I'm referring to the book 'Head First Design Patterns'. For anybody who has the book, this is on page 251.

A little bit of the background-- I have understood that the adapters basically convert an interface to the type the client expects so incompatible types can work together. Object Adapters do this using composition ( the adapter encapsulates the adaptee and implements the target interface by delegating the target interface method calls to adaptee method calls and/or adding extra processing if required ) and Class Adapters do this using multiple inheritance ( they subclass both the adaptee and the target ). Since Java does not support multiple inheritance, we will only talk about object adapters.

So given below is a simple Enumeration Iterator that adapts an Enumeration to an Iterator.



So far, so good.
But now on page 251, in the Brain Power section, the authors state the following --

Head First Design Patterns wrote:"Some AC adapters do more than just change the interface - they add other features like surge protection, indicator lights and other bells and whistles. If you were going to implement these kinds of features, what pattern would you use?"



I've been thinking about this question for some time and I don't have an answer. The reason is all adapter implementations would implement a target interface that is already designed. When we code, we code to an interface, not to an implementation. So we can't really invoke methods that aren't a part of target interface.

I think I have probably not understood the question because no matter what pattern we use, the target interface has only four methods, so my adapter can't just add features that aren't provided by the target interface. Or can we?

Could someone please advice.

Thanks.
 
Heena Agarwal
Ranch Hand
Posts: 262
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok, I think I've got this one. The authors aren't saying we are adding more methods to the interface, it is the features we are adding and features can be added without changing the interface. I think I could use a decorator for that.


 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Heena Agarwal wrote:Ok, I think I've got this one. The authors aren't saying we are adding more methods to the interface, it is the features we are adding and features can be added without changing the interface. I think I could use a decorator for that.


There's some overlap between the two, but Decorator is usually used to add behaviour to an existing class without disturbing it, whereas Adapter is more about changing what it does.

A good example of an Adapter is Arrays.asList(), which returns an (unknown) class that actually turns an array into a List. An example of a Decorator might be a scrollable pane in a GUI. Again, exactlly what constitutes "adding" and "changing" are a bit debatable, but I usually think of an Adapter as doing something that the designer of the original class never invisaged, whereas Decorator simple adds something (like a scrollbar) that they may well have thought about, but decided to keep separate. I'm not sure that there are any hard and fast rules about it though.

Also: Decorator usually preserves the original API, whereas Adapter can completely change it.

Winston
 
Heena Agarwal
Ranch Hand
Posts: 262
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks, Winston. Those are really nice examples. Arrays.asList() was an interesting example of an adapter. I did understand the adapting part of an adapter, it's the enhancing the interface part that I was a little confused about.

I thought that the adapter was supposed to enhance the target interface in a way that those enhancements would be independent functions. So I thought that I was supposed to add a new method to say my EnumerationIterator. Granted I can add that method, but I have really not enhanced the Iterator interface this way cause I can't invoke it if all I know is that EnumeratorIterator is an Iterator.

What I mean is I can't do this for example--


But I can have myIt invoke a method that is declared in the Iterator interface, say the remove method and have my implemented version of remove() method invoke myNewMethod().

I know that an adapter adapts an adaptee to a target interface but I am not really sure how an adapter can enhance a target interface. Perhaps by new features the authors meant the same things as having a new implementation of methods declared by the interface and these new implementations can invoke new features. But I'm not too sure about this.

I understand how a decorator adds additional behavior.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic