Pattern:Adapter
From TheModelFactory
| Adapter Pattern Design Pattern - Structural | |
| Wrap a class to provide another interface | |
| Author | Origin |
|---|---|
| TMF | GoF |
| Diagram | |
| Share | |
|
| |
The Adapter pattern provides a mechanism to use classes with an interface that is not compatible with the client and adapt their interface to the requirements of the client.
This pattern is often used when integrating a third party toolset into an application. The Adaptee is in that case a class provided by the toolset. In your client application you do not wish to be dependent on the interface of the classes in the toolset.
Another reason to use the Adapter pattern might be that the Adaptee does not provide all the functionality required by the client. This functionality can then be added to the Adapter class. The Adapter will delegate as much of the functionality as possible to the Adaptee, but will implement the missing parts himself.
When using this pattern you first create the Adapter classes and their operations as if you are implementing everything yourself. Once the interface is suitable for your needs you figure out which classes and operations from the Adaptee you need to implement the required functionality. You can even wrap several Adaptees into one Adapter, if their combined behavior adds up to the required functionality.
If the toolset you are using provides all required functionality your Adapter will be a fairly thin pass through gate. It merely delegates to the appropriate operation on the Adaptee. If the toolset only provides part of the required functionality then you add the extra logic to the adapter methods.
Contents |
Area of Applicability
When to use
- you want to use a third party toolset but you don't want your client to become dependent on the toolset.
In your application you are using a toolset provided by a third party. It could very well happen (and it happens quite a lot in practice) that one day, for some reason, you have to change to a different third party toolset. If you don't use adapters (or wrapper classes) but just use the provided classes in the toolset as is then you will have to search the whole application for usage of the toolset classes and change every usage thereof. When using adapters the change is limited to the adapter classes. No logic in the main application has to be changed. - the third party toolset does not provide all the required functionality.
In this case you wrap the classes from the toolset and add the extra functionality to the adapter class.
When not to use
- when the classes playing the role of adaptee can be changed to suit your needs.
In this case using adapters would only make the whole more complex, without having added value.
- when resources are limited and performance is critical
This is the classical trade-off between flexibility and simplicity. Using adapters increases your flexibility but at the same time increases the complexity and usage of resources since usually each class in the toolset is wrapped in an extra adapter.
Example of Usage
This example features an application to read an ADL model and import it into a UML model in a CASE tool.
ADL or Abstract Domain Language is an abstract condense language to describe elements in a domain. It is used by UmlCanvas to describe a UML diagram to display on a web page.
In this case the ADLImporter is the client in the adapter pattern. Because we do not want to limit the application to just one CASE tool, we have added the abstract class UseCase as an extra abstraction layer between the adapter and the client. ADLImporter now only talks to the UseCase class, irrespective of which adapter is implementing the UseCase.
The adapters are the EAUseCase which wraps the EA.Element class from the API of Enterprise Architect, and the RSAUseCase which wraps the RSA.UseCase class from the API of Rational Software Architect.
Using this design we could very easily add support for another CASE tool by just adding the appropriate adapters.
Integration
- see Pattern:Abstract Factory#Integration for integration between Adapter and Abstract Factory.
- see Pattern:Builder#Integration for integration between Adapter and Builder.
References
Design Patterns: Elements of Reusable Object-Oriented Software
