1. S.Ducasse 1
QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture.
Stéphane Ducasse
Stephane.Ducasse@univ-savoie.fr
http://www.listic.univ-savoie.fr/~ducasse/
Adapter

2. S.Ducasse 2
License: CC-Attribution-ShareAlike 2.0
http://creativecommons.org/licenses/by-sa/2.0/

3. S.Ducasse 3
Adapter
• Convert the interface of a class into another interface
clients expect.
• Adapter lets classes work together that couldn't
otherwise because of incompatible interfaces.
• Aka:Wrapper

4. S.Ducasse 4
Motivation
• Sometimes a toolkit class designed for reuse isn't
reusable only because its interface doesn't match the
domain-specific interface an application requires.

5. S.Ducasse 5
Adapter Solution

6. S.Ducasse 6
Possible Adapter Structures

7. S.Ducasse 7
Participants
• Target (Shape)
• defines the domain-specific interface that Client uses.
• Client (DrawingEditor)
• collaborates with objects conforming to the Target
interface.
• Adaptee (TextView)
• defines an existing interface that needs adapting.
• Adapter (TextShape)
• adapts the interface of Adaptee to the Target interface.

8. S.Ducasse 8
Collaborations
• Clients call operations on an Adapter instance. In turn,
the adapter calls Adaptee operations that carry out
the request.

9. S.Ducasse 9
About Identity
• A decorator and its component aren't identical.
• A decorator acts as a transparent enclosure. But from
an object identity point of view, a decorated
component is not identical to the component itself.
• If the decorator is wrapping, then identity of the
object may change.
• Good at construction time, but else should “adapt”
the references from the decorated to the decorator.

10. S.Ducasse 10
Consequences
• More flexibility than static inheritance. Dynamic
addition of properties
• Avoids feature-laden classes high up in the hierarchy.
• Lots of little objects.

11. S.Ducasse 11
Implementation
• Interface conformance. A decorator object's
interface must conform to the interface of the
component it decorates. ConcreteDecorator classes
must therefore inherit from a common class (at least
in C++).
• Omitting the abstract Decorator class. There's no
need to define an abstract Decorator class when you
only need to add one responsibility.
• Keeping Component classes lightweight.
Component should specify an interface, decorators
are then easier to define

12. S.Ducasse 12
Wrapping or not? Conforming or
not
• With decorator
• With strategies

13. S.Ducasse 13
Strategies?
• Strategies are a better choice when the Component
class is heavyweight, thereby making the Decorator
pattern too costly to apply.
• The Strategy-based approach might require modifying
the component to accommodate new extensions.
• - a strategy can have its own specialized interface,
• - a decorator's interface must conform to the
component's.
• A strategy needs only define the interface for
rendering a border, which means that the strategy can
be lightweight even if the Component class is

14. S.Ducasse 14
Known Uses
• VisualWorks Wrapper hierarchy
• Stream Decorators inVisualWorks:
• BOSSTransporter is a stream decorator
• FormattedStream is a stream decorator