Adapter Pattern

Shin-Jie Lee (李信杰)

Associate Professor
Computer and Network Center
Department of CSIE
National Cheng Kung University
Design Aspect of Adapter

Interface to an object

2
 Outline

 Requirements Statement
 Initial Design and Its Problems
 Design Process
 Refactored Design after Design Process
 Another Example
 Recurrent Problems
 Intent
 Object Adapter Pattern Structure
 Class Adapter Pattern Structure
 Object Adapter vs. Class Adapter
 Homework

3
 New Vendor in
Existing Software

Shin-Jie Lee (李信杰)

Assistant Professor
Computer and Network Center
Department of CSIE
National Cheng Kung University
 Requirements Statement1
 You’ve got an existing client class that use a vendor class library.

ExistingClient VendorClass
vendor specificRequest()
request()

{
vendor.specificRequest();
}

5
 Requirements Statement2
After a while you found another vendor class
library is better, but the new vendor designed their
interfaces differently.
ExistingClient NewVendorClass
newvendor
request() newSpecificRequest(int i)

{
newvendor.newSpecificRequest(i);
}

6
Initial Design

ExistingClient NewVendorClass
newvendor
request() newSpecificRequest(int i)

{
newvendor.newSpecificRequest(i);
}

7
 Problems with Initial Design

ExistingClient NewVendorClass

request() newSpecificRequest(int i)

Problem: The request method of the existing {

software should be modified once it changes its newSpecificRequest(i);
}
vendor class with a new interface.

8
 Design Process for Change

Design Principle: Encapsulate what

The code that changes has been varies.
encapsulated as a class?

Need abstraction?
Act-1: Encapsulate
No What Varies, methods No
and its corresponding
attributes Need composition?
Yes Yes

Act-2: Abstract Common Behaviors No

(with a same signature) into Interfaces
or Abstract Classes Yes

Design Principle: Program to an

interface, not an implementation.

Act-3: Compose or
Delegate Abstract Expose new interfaces?
Design Principle: Depend on
abstractions. Do not depend on Behaviors
concrete classes.

Yes No

9
Act-1: Encapsulate What Varies

NewVendorClass
Act-1.2: Encapsulate a
newSpecificRequest()
method into a concrete
ExistingClient class AdapterForNew
vendor
request() request()

VendorClass
{
newvendor.newSpecificRequest(); specificRequest()
}

AdapterForOld
vendor
request()

10
 Act-2: Abstract Common
Behaviors
Object Adapter Structure

ExistingClient <<interface>> NewVendorClass OldVendorClass

CommonInvoker
newSpecificRequest() specificRequest()
request()

Act-2.1: Abstract common behaviors newvendor vendor

with a same signature into interface
through polymorphism

AdapterForOld AdapterForNew

request() request()

{
newvendor.newSpecificRequest();
}

11
Refactored Design after Design Process
– Object Adapter

ExistingClient <<interface>> NewVendorClass OldVendorClass

CommonInvoker
newSpecificRequest() specificRequest()
request()

newvendor vendor

AdapterForOld AdapterForNew

request() request()

{
newvendor.newSpecificRequest();
}

12
 Requirements Statement1
 You’ve got an existing client class that use a vendor class library by
inheritance.

VendorClass

specificRequest()

ExistingClient

request()

{
specificRequest();
}

13
 Requirements Statement2
After a while you found another vendor class
library is better , but the new vendor designed
their interfaces differently.
NewVendorClass

newSpecificRequest(int i)

ExistingClient

request()

{
newSpecificRequest(i);
}

14
Initial Design

NewVendorClass

newSpecificRequest(int i)

ExistingClient

request()

{
newSpecificRequest(i);
}

15
 Problems with Initial Design

NewVendorClass

newSpecificRequest(int i)

ExistingClient

request()

Problem: The request method of the existing {

software should be modified once it changes its newSpecificRequest(i);
}
vendor class with a new interface.

16
 Design Process for Change

Design Principle: Encapsulate what

The code that changes has been varies.
encapsulated as a class?

Need abstraction?
Act-1: Encapsulate
No What Varies, methods No
and its corresponding
attributes Need composition?
Yes Yes

Act-2: Abstract Common Behaviors No

(with a same signature) into Interfaces
or Abstract Classes Yes

Design Principle: Program to an

interface, not an implementation.

Act-3: Compose or
Delegate Abstract Expose new interfaces?
Design Principle: Depend on
abstractions. Do not depend on Behaviors
concrete classes.

Yes No

17
Act-1: Encapsulate What Varies

Act-1.2:
NewVendorClass OldVendorClass
ExistingClient
Encapsulate a
newSpecificRequest() specificRequest()
request()
method into a
concrete class

AdapterforNew AdapterforOld

{ request() request()
newSpecificRequest();
}

18
 Act-2: Abstract Common
Behaviors
Class Adapter Structure

ExistingClient <<interface>> NewVendorClass OldVendorClass

CommonInvoker
newSpecificRequest() specificRequest()
request()

Act-2.1: Abstract common

behaviors with a same signature
into interface through polymorphism

Adapter Adapter

request() request()

19
Refactored Design after Design Process – Class
Adapter

ExistingClient <<interface>> NewVendorClass OldVendorClass

CommonInvoker
newSpecificRequest() specificRequest()
request()

Adapter Adapter

request() request()

20
A Text Shape

Shin-Jie Lee (李信杰)

Assistant Professor
Computer and Network Center
Department of CSIE
National Cheng Kung University
 Requirements Statement1
A drawing editor
 Want to add a TextShape that using display method to
display text and using boundingBox method to get
bounding.

TextShape
Drawing Editor
display()
boundingBox()

22
 Requirements Statement2
A drawing editor
 Meanwhile, an external library already provide a
TextView class using display method to display text
and using getExtent method to get bounding.
 We'd like to reuse TextView to display text of shape.
TextShape TextView
DrawingEditor
TextView
display() display()
boundingBox() getExtent()

{
{
textView.display();
textView.getExtent();
}
}

23
Initial Design - Class Diagram

TextShape TextView
DrawingEditor
textView
display() display()
boundingBox() getExtent()

{
{
textView.display();
textView.getExtent();
}
}

24
 Problems with Initial Design

Problem: The display and boundingBox methods

of the shape should be modified once it changes
its external library class with a new interface.

TextShape TextView
DrawingEditor
textView
display() display()
boundingBox() getExtent()

{
{
textView.getExtent();
textView.display();
}
}

25
Act-2: Compose Abstract Behaviors

Object Adapter Structure

DrawingEditor <<interface>> TextView

Shape
display()
display() getExtent()
boundingBox()

Act-2.1:
Abstract
common TextShape

behaviors display()
boundingBox()

26
 Requirements Statement1
A drawing editor
 Want to add a TextShape that using display method to
display text and using boundingBox method to get
bounding.

TextShape
Drawing Editor
display()
boundingBox()

27
 Requirements Statement2
A drawing editor
 Meanwhile, an external library already provide a
TextView class using display method to display text
and using getExtent method to get bounding.
 We‘d like to reuse TextView to display text of shape by
inheritance. TextView

display()
getExtent()

TextShape
DrawingEditor
display()
boundingBox()
{
display(); {
} getExtent();
}

28
 Initial Design - Class Diagram

Problem: The display and boundingBox methods TextView

of the shape should be modified once it changes display()
its external library class with a new interface. getExtent()

TextShape
DrawingEditor
display()
boundingBox()

{ {
display(); getExtent();
} }

29
Act-2: Abstract Common
Behaviors

Class Adapter Structure

DrawingEditor <<interface>> TextView

Shape
display()
display() getExtent()
boundingBox()

Act-2.1:
Abstract
common TextShape

behaviors display()
boundingBox()

30
Act-3: Compose Abstract
Behaviors
Object Adapter Structure

DrawingEditor <<interface>> TextView

Shape
display()
display() getExtent()
boundingBox()

TextShape

display()
boundingBox()

Act-3.6: Compose behaviors

of a concrete class

31
 Recurrent Problem
The request method of the requester object should
be modified once it changes its receiver class with
a new interface.
 Sometimes a toolkit class that's designed for reuse isn't
reusable only because its interface doesn't match the
domain-specific interface an application requires.

32
 Adapter Pattern
 Intent
 Convert the interface of a class into another interface clients
expect. Adapter lets classes work together that couldn't
otherwise because of incompatible interfaces.

33
Object Adapter Pattern
Structure1

<<interface>>
Client Target Adaptee
request() specificRequest()

Adapter
specificRequest(); request();

34
Object Adapter Pattern
Structure2

Client Adapter Adaptee

1: request() 2: specificRequest()

35
 Object Adapter Pattern
Structure3

Instantiation Use Termination

Target X Client sends a request to Target. X

Client sends a request to Adapter through Adapter is terminated

Adapter Don’t Care polymorphism, and then Adapter delegates when Client no longer
to Adaptee to finish the request. needs it.

Adapter creates Adaptee

Adaptee is terminated
or somebody creates
Adaptee Adapter delegates the request to Adaptee. when Adapter no
Adaptee and sends its
longer needs it.
reference to Adapter.

36
Class Adapter Pattern
Structure1

<<interface>>
Client Target Adaptee
request() specificRequest()

Adapter
specificRequest(); request();

37
Class Adapter Pattern
Structure2

Client Adapter

1: request()
2: specificRequest()

38
 Class Adapter Pattern
Structure3

Instantiation Use Termination

Target X Client sends a request to Target. X

Client sends a request to Adapter through

polymorphism, and then Adapter completes Adapter is terminated when
Adapter Don’t Care
the request by invoking the method Client no longer needs it.
inherited from Adaptee.

Adapter invokes the method inherited from

Adaptee Don’t Care Don’t Care
Adaptee to complete the request.

39
 Object Adapter vs. Class
Adapter

Object Adapter Class Adapter

Design Concept Use object composition. Based on the concept of inheritance.
The Adaptee itself A class adapter won't work when we
Adapt subclasses of
and all of its subclasses (if any). want to adapt a class and all its
the Adaptee
subclasses.
Can not override Adaptee methods. It is possible to override some of
Overriding
Adaptee’s behaviors.

40