Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
"Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldnt otherwise because of incompatible interfaces." (Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995)
Sometimes a toolkit class thats designed for reuse isnt reusable only because its interface doesnt match the domain-specific interface an application requires. Consider a drawing editor that lets users draw and arrange graphical elements (lines, polygons, text, etc.) into pictures and diagrams. The drawing editors key abstraction is the graphical object, which has an editable shape and can draw itself. The interface for graphical objects is defined by an abstract class called Shape (Target in the thumbnail). The editor defines a subclass of Shape for each kind of graphical object: a LineShape class for lines, a PolygonShape class for polygons, and so forth. Classes for elementary geometric shapes like LineShape and PolygonShape are rather easy to implement, because their drawing and editing capabilities are inherently limited. But a TextShape subclass (Adapter in the thumbnail) that can display and edit text is considerably more difficult to implement, since even basic text editing involves complicated screen update and buffer management. Meanwhile, an off-the-shelf user interface toolkit might already provide a sophisticated TextView (Adaptee in the thumbnail) class for displaying and editing text. We could define TextShape so that it adapts the TextView interface to Shapes. We can do this in one of two ways: (1) by inheriting Shapes interface and TextViews implementation or (2) by composing a TextView instance within a TextShape and implementing TextShape in terms of TextViews interface. These two approaches correspond to the class and object versions of the Adapter pattern. TextShape is an adapter.
This pattern has been used on the following systems: InterViews 2.6 defines an Interactor abstract class and a Graphic abstract class. Both have graphical appearances but they have different interfaces and implementations (they share no common parent). Interviews 2.6 defines an object adapter called GraphicBlock, a subclass of Interactor that conatins a Graphic instance. The GraphicBlock adapts the interface of the Graphic class to that of Interactor, a Graphic instance can be displayed, scrolled, etc. within an Interactor structure. (Vlissides, J.M. and M.A. Linton, Applying object-oriented design to structured graphics. In Proceedings of the 1988 USENIX C++ Conference, pp. 81-94, Denver, CO, October 1988. USENIX Association.) Interface adaptation using delegate objects is performed in some classes in NeXTs AppKit. For example, the NXBrowser class can display hierarchical lists of data. To access and adapt the data, the NXBrowser uses a delegate object. (Addison-Wesley, Reading, MA. NEXTSTEP General Reference: Release 3, Volumes 1 and 2, 1994.) Pluggable adapters are common in ObjectWorks\Smalltalk. Standard Smalltalk defines a ValueModel class for views that display a single value. ValueModel defines a "value, value:" interface for accessing the value. ObjectWorks\Smalltalk includes a subclass of ValueModel called PluggableAdaptor. A PluggablelAdaptor object adapts other objects to the ValueModel interface (value, value:). It can be parameterized with blocks for getting and setting the desired value. PluggableAdapter uses these blocks internally to implement the "value, value:" interface. PluggableAdaptor also lets you pass in the selector names (e.g., width, width:) directly for syntactic convenience. (ParcPlace Systems, Mountain View, CA. ObjectWorks\Smalltalk Release 4 Users Guide, 1990.)
Bridge, Decorator,and Proxy patterns
Bridge pattern, Decorator pattern, Proxy pattern, structural patterns, Gamma patterns, Adapter Class pattern, Adapter Object pattern, Wrapper pattern, interfaces (existing, incompatible), pluggable adapters, forward requests
any system integrated with multiple, disparate systems
need a class that is reusable in multiple, unforeseen contextsneed to de-couple a class and its implementationneed to use an existing class but the interface is not compatible with another class
increases reuse of classes by de-coupling the interface from the implementation