This document discusses the adapter pattern in object-oriented programming. The adapter pattern allows classes with incompatible interfaces to work together by converting the interface of one class into another interface that clients expect. An adapter acts as a bridge between two incompatible interfaces. It adapts the interface of an existing class (the adaptee) so that its interface conforms to what the client expects (the target interface). An example is provided where a class that sorts lists is adapted to sort arrays by converting between the list and array interfaces.

1. ADAPTER
PATTERN
Adeel Riaz
Mirza Danish Baig
Malik Mohammad Sohaib
Farhan Ahmed
Advisor: Muhammad Qasim pasta
PAF KIET Fall 11
1

2. Real World Adapter
Slide 2
PAF KIET Fall 11

3. Adapter in our Object Oriented
Slide 3
PAF KIET Fall 11

4. Problem in Object Oriented??
Slide 4
PAF KIET Fall 11

5. Problem in Object Oriented??
Slide 5
I have already written class called xyzcircle that deals with circles
already. But we can’t use directly because I want to preserve polymorphic
behavior with Shape
PAF KIET Fall 11

6. Problem in Object Oriented??
Slide 6
PAF KIET Fall 116

7. 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.
 Also Known As -> Wrapper
Slide 7
PAF KIET Fall 11

8. Motivation
 Sometimes a toolkit or class library can not
be used because its interface is incompatible
with the interface required by an application
 We can not change the library interface,
since we may not have its source code
 Even if we did have the source code, we
probably should not change the library for
each domain-specific application
Slide 8
PAF KIET Fall 11

9. Motivation
 Example:
Slide 9
PAF KIET Fall 11

10. Applicability
Use the Adapter pattern when
 You want to use an existing class, and
its interface does not match the one you
need
 You want to create a reusable class
that cooperates with unrelated classes
with incompatible interfaces
Slide 10
PAF KIET Fall 11

11. Structure
 An object adapter relies on object
composition:
Slide 11
PAF KIET Fall 11

12. Participants
 Target (Shape)
• defines the domain-specific interface that Client
uses.
 Adapter (Line,TextShape)
• adapts the interface Adaptee to the Target
interface.
 Adaptee (TextView)
• defines an existing interface that needs adapting.
 Client (DrawingEditor)
• collaborates with objects conforming to the Target
interface.
Slide 12
PAF KIET Fall 11

13. Example
Slide 13
PAF KIET Fall 11

14. Example
Slide 14
PAF KIET Fall 11

15. Sequence Diagram
Slide 15
PAF KIET Fall 11

16. Consequences
 Class adapter
 Concrete Adapter class
 Unknown Adaptee subclasses might cause problem
 Object adapter
 Adapter can service many different Adaptees
 May require the creation of Adaptee subclasses and
referencing those objects
Slide 16
PAF KIET Fall 11

17. Implementation
slide 17
 How much adapting should be done?
 Simple interface conversion that just changes
operation names and order of arguments
 Totally different set of operations
 Does the adapter provide two-way
transparency?
 A two-way adapter supports both the Target and
the Adaptee interface. It allows an adapted
object (Adapter) to appear as an Adaptee object
or a Target object
PAF KIET Fall 11

18. Comparing the Facade Pattern with the
Adapter Pattern
Slide 18
 In both the Facade and Adapter pattern I have preexisting classes.
 In the Facade, however, I do not have an interface I must design to, as I do in the Adapter
pattern.
 I am not interested in polymorphic behavior in the Façade, while in the Adapter, I probably
am. (There are times when we just need to design to a particular API and therefore must use
an Adapter. In this case, polymorphism may not be an issue— that's why I say "probably").
 In the case of the Facade pattern, the motivation is to simplify the interface. With the
Adapter, while simpler is better, I am trying to design to an existing interface and cannot
simplify things even if a simpler interface were otherwise possible.
PAF KIET Fall 11

19. Example 1
slide 19
 Consider that we have a third party library that provides sorting
functionality through it's NumberSorter class. This is our Adaptee
/*
* This is our adaptee, a third party implementation of a
* number sorter that deals with Lists, not arrays.
*/
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
PAF KIET Fall 11

20. Example 1 (continued)
slide 20
 Our Client deals with primitive arrays rather than
Lists. For the sake of this example, lets say we can't
change the client to use Lists.
We've provided a Sorter interface that expects the client
input. This is our target.
//this is our Target interface
public interface Sorter
{
public int[] sort(int[] numbers);
}
PAF KIET Fall 11

21. Example 1 (continued)
slide 21
 Finally, the SortListAdapter implements our target interface and deals
with our adaptee, NumberSorter
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);
//convert the list back to an array and return
return sortedNumbers;
}
}
PAF KIET Fall 11

22. Example 1 (Continued)
slide 22
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
PAF KIET Fall 11

23. Questions?
slide 23
PAF KIET Fall 11