1 Dept. of Computer Science & Engineering, York University, Toronto CSE3311 Software Design Adapter Pattern Façade pattern

2 Being Adaptive  Or, how to perform the impossible feat of putting a square peg in a round hole

3 Design Problem Our windowing toolkit has a drawing editor with class SHAPE with bounding box: bottom_left, top_right: POINT2D Classes such as LINE and POLYGON inherit from SHAPE An off the shelf user interface toolkit (e.g. a.NET component) has a TEXT_VIEW to display and edit text with sophisticated screen update and buffering capabilities. It’s bounding box is: origin: POINT2D width, height: REAL

4 SHAPE vs. TEXT_VIEW  SHAPE assumes a bounding box defined by its opposing corners  TEXT_VIEW is defined by its origin, height and width.

5 Requirements  We would like to re-use TEXT_VIEW as a SHAPE  However, they have incompatible interfaces  How would you re-arrange the classes so that TEXT_VIEW can be treated as a shape?  Environmental constraint: We cannot change the interface or implementation of TEXT_VIEW

6 Design 1  Change the TEXT_VIEW class’s features so that it’s interface is compatible with SHAPE  Problem: We don’t have TEXT_VIEW’s source code – hence it is fixed in stone (e.g. a.NET assembly).  Even if we have the source code, why should we have to change the interface just to make one application work.  Recall the open-closed principle

7 Design 2  Recall the open-closed principle  Adapter Pattern

8 Non-software analogy  North American equipment electricity requirements: 110V, 60 Hz.  European electricity: 220V, 50 Hz.  Not practical to  Buy new equipment (computer, ipod etc) when traveling  Build a new electricity transmission system while in Europe  Solution  Use an adapter

9

10 How?

11 Client-supplier adaptor

12 TEXT_VIEW TEXT_SHAPE

13

14 Adapter – Context  You want to use an existing class (TEXT_VIEW) without modifying it  Adaptee  The context in which you want to use the class requires conformance to an interface that is different from that of the adaptee  Target (SHAPE)  The target interface and the adaptee interface are conceptually related

15 Adapter – Solution  Define an adapter class (TEXT_SHAPE) that implements the target interface  The adapter class holds a reference to the adaptee. It translates target methods to adaptee methods

16 Inheritance Adapter

17 Two Kinds of Adapters  TEXT_SHAPE inherits SHAPE's interface and TEXT_VIEW's implementation.  Inheritance Adapter  TEXT_SHAPE2 inherits SHAPE's interface and uses TEXT_VIEW's implementation.  Client-Supplier Adapter (also mistakenly called object adapter)

18 Participants  Target (SHAPE)  defines the domain-specific interface that Client uses.  Client (DrawingEditor)  collaborates with objects conforming to the Target interface.  Adaptee (TEXT_VIEW)  defines an existing interface that needs adapting.  Adapter (TEXT_SHAPE)  adapts the interface of Adaptee to the Target interface.

19 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 or unforeseen classes, that is, classes that don't necessarily have compatible interfaces.  (object adapter only) you need to use several existing subclasses, but it's impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class.

20 Consequences  Class and object adapters have different trade-offs. A class adapter  adapts Adaptee to Target by committing to a concrete Adapter class. As a consequence, a class adapter won't work when we want to adapt a class and all its subclasses.  lets Adapter override some of Adaptee's behavior, since Adapter is a subclass of Adaptee.  introduces only one object, and no additional pointer indirection is needed to get to the adaptee.  An object adapter  lets a single Adapter work with many Adaptees—that is, the Adaptee itself and all of its subclasses (if any). The Adapter can also add functionality to all Adaptees at once.  makes it harder to override Adaptee behavior. It will require subclassing Adaptee and making Adapter refer to the subclass rather than the Adaptee itself.

21 Eiffel has rich adapter mechanisms  Rename  Redefine  Changing export status  OOSC2 chapter 15 (Multiple inheritance)  Undefine  Select

22 Adapter real-world examples  java.io.Reader is an abstract class for reading character streams [TARGET]  Contains an abstract method read(char[],int,int)  java.io.InputStream represents an input stream of bytes [ADAPTEE]  Contains method read(byte[],int,int)  java.io.InputStreamReader is an adapter from byte streams to character streams [ADAPTER]  Implements read(char[],int,int) using read(byte[],int,int)

23 Adapter Pattern Intent  Convert the interface of a class into another interface that clients expect.  Adapter lets classes with otherwise incompatible interfaces work together

24  And now for something different  another quick pattern

25  Turn on the popcorn popper  Start the popper popping  Dim the lights  Put the screen down  Turn projector on  Set projector input to DVD  set to wide screen  set amp to DVD in  set amp to suuround sound  set amp volume to med  start DVD  ……..

26

27

28  This principle prevents us from creating designs that have a large number of classes coupled together so that changes in one part of the system cascade to other parts. When you build a lot of dependencies between many classes, you are building a fragile system that will be costly to maintain and complex for others to understand.  See OOSC2 p46-53:  Every module should communicate with as few others as possible  If two modules communicate, they should exchange as little information as possible

29