Utilization

[Previous] [Next]

The Adapter design pattern is useful in the following circumstances:

• The application's architecture requires a specific interface, but the class you want to use is located in a compiled class library (such as a Microsoft Visual Basic in-process ActiveX DLL or a Microsoft Visual C++ out-of-process ActiveX server) and doesn't support the interface. Because you don't have access to the source code for the class library, adding a new interface to an existing class via inheritance is not an option.
• Implementing a new interface in an existing class proves to be impractical. A single class might be overloaded with the implementation of numerous interfaces in an attempt to improve the utility value gained by each caller. For example, if a class inherited from 100 different interfaces, and each unique caller utilized a single unique interface, the overhead incurred by the implementation of all these interfaces outweighs the utility value gained by each caller.
• The functionality to support a specific interface is dispersed among many existing classes in a system. Instead of maintaining separate object references to each class instance needed, you could define a new class that exposes a single interface that internally maintains references to the required class instances. Not only do you simplify access to a set of objects, but you also encapsulate the logic that determines which objects to use when.
• Plugging in to the functionality of existing non-object-oriented legacy code makes sense. It is often the case that a firm has already invested a considerable amount of time and money in developing services in legacy code. Using the Adapter design pattern to reference the legacy code might be more cost-effective than rewriting the code as an object-oriented solution.
• The intention is to extend the functionality of an object without modifying its interface. This will result in a transparent adapter (explained in the next section).