Adapters Presented By Zachary Dea

Definition A pattern found in class diagrams in which you are able to reuse an ‘adaptee’ class by providing a class, (the adapter) that delegates to the adaptee. AKA: Wrapper

Typical Context 1.You are building an inheritance hierarchy and you want to incorporate into it a class written by somebody else - i.e. you want to reuse an existing class. 2.Typically the methods of the reused class do not have the same name or argument types as the methods in the hierarchy you are creating. 3.The reused class is also often already part of its own inheritance hierarchy.

Problem How do you obtain the power of polymorphism when reusing a class whose methods have the same function but do not have the same signature as the other methods in the hierarchy?

Solution 1.Rather than directly incorporating the reused class into your inheritance hierarchy, instead incorporate an «Adapter» class. 2.The «Adapter» is connected by an association to the reused class, which we will call the «Adaptee». 3.The polymorphic methods of the «Adapter» delegate to methods of the «Adaptee».

A Drawing Program Example Consider a drawing editor. Top level data type is the “graphical object” Subclasses of the “graphical object” class: LineShape, PolygonShape, TextShape etc.

The TextShape Class The TextShape class is considerably more difficult to implement than simple polygon classes. We have a user-interface toolkit which provides a reusable “TextView” class for displaying and editing text. TextView was not developed with our shape-class oriented design in mind. Sounds like we need an adapter!

Interface Differences 1.TextView uses different names for it’s functions. 2.TextView lacks the functionality for interactive “dragging” of text etc, which our graphical object requires.

Adapter’s Solutions 1.The Adapter provides our graphical object class with functions under the expected name which simply call the appropriate functions in TextView. 2.The Adapter can contain additional functions such as a “TextManipulator” which will be responsible for the unsupported functionality.

Structure 1.Class Adapter –Uses multiple inheritance to adapt one interface to another. 2.Object Adapter –Relies on object composition.

Adapter Class Diagram (Class Adapter) Client Target Request() Adaptee SpecificRequest() Adapter Request() SpecificRequest() (implementation)

(class) Adapter Class Diagram: Example by Rob Kremer, Professor of Computer Science at Calgary University Client Target Request() Adaptee SpecificRequest() Adapter Request() SpecificRequest() (implementation) List InsertAtFront() Get Front() RemoveFront() Queue Push() Pop() QueueImp Push() Pop() InsertAtFront() We have a list… We want a queue… Adapter to the rescue! x := GetFront(); RemoveFront(); return x;

Consequences (Class Adapter) The class adapter adapts adaptee to the target interface by committing to a concrete adaptee class. Thus a class adapter won’t work when we want to adapt a class and all it’s subclasses. The adapter can override some of adaptee’s behavior, since the adapter is a subclass of the adaptee. It introduces only one object, thus no additional pointer indirection is needed to get to the adaptee.

Adapter Class Diagram (Object Adapter) Client Target Request() Adaptee SpecificRequest() Adapter Request() SpecificRequest() Adaptee->SpecificRequest() adaptee

Client Target Request() Adaptee SpecificRequest() Adapter Request() SpecificRequest() (implementation) Use a pointer to an instance of the the adaptee Change the code of Request() to use the pointer Adaptee->SpecificRequest() adaptee (object) Adapter Class Diagram: Example by Rob Kremer, Professor of Computer Science at Calgary University

Consequences (Object Adapter) Using an object adapter let’s a single adapter work with many adaptees, i.e.. the adapter itself and all it’s subclasses. It also makes it harder to override adaptee behavior. Doing so will require subclassing adaptee and making adapter refer to the subclass instead of the adapter itself.

Things to keep in mind for Adapters 1.should be as general as possible 2.should be described in an easy-to- understand form so that people can determine when and how to use it 3.should contain a solution that has been proven to effectively solve the problem in the indicated context 4.should be illustrated using a simple diagram 5.should be written using a narrative writing style

Adapters are one of the Gang of Four patterns Others include: Facade Read-only interface Proxy

References: Design Patters: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides Object Oriented Software Engineering Knowledge Base, Knowledge base was created from the book "Object Oriented Software Engineering: Practical Software Development using UML and Java“ by Timothy C. Lethbridge and Robert Laganière published by McGraw Hill in Summer Diagrams taken from Prof Rob Kremer’s “Notes from Design Patterns: Elements of Reusable Object-Oriented Software, The Adapter and Bridge Patterns”