Adapter Design Pattern
Last Updated :
04 Feb, 2024
The Adapter design pattern is a structural pattern that allows the interface of an existing class to be used as another interface. It acts as a bridge between two incompatible interfaces, making them work together. This pattern involves a single class, known as the adapter, which is responsible for joining functionalities of independent or incompatible interfaces.
Let’s understand this concept using a simple example:
Let’s say you have two friends, one who speaks only English and another who speaks only French. You want them to communicate, but there’s a language barrier.
- You act as an adapter, translating messages between them. Your role allows the English speaker to convey messages to you, and you convert those messages into French for the other person.
- In this way, despite the language difference, your adaptation enables smooth communication between your friends.
- This role you play is similar to the Adapter design pattern, bridging the gap between incompatible interfaces.
Important Topics for the Adapter Design Pattern
Components of Adapter Design Pattern
1. Target Interface
- Description: Defines the interface expected by the client. It represents the set of operations that the client code can use.
- Role: It’s the common interface that the client code interacts with.
2. Adaptee
- Description: The existing class or system with an incompatible interface that needs to be integrated into the new system.
- Role: It’s the class or system that the client code cannot directly use due to interface mismatches.
3. Adapter
- Description: A class that implements the target interface and internally uses an instance of the adaptee to make it compatible with the target interface.
- Role: It acts as a bridge, adapting the interface of the adaptee to match the target interface.
4. Client
- Description: The code that uses the target interface to interact with objects. It remains unaware of the specific implementation details of the adaptee and the adapter.
- Role: It’s the code that benefits from the integration of the adaptee into the system through the adapter.
Adapter Design Pattern Example
Problem Statement
Let’s consider a scenario where we have an existing system that uses a LegacyPrinter class with a method named printDocument() which we want to adapt into a new system that expects a Printer interface with a method named print(). We’ll use the Adapter design pattern to make these two interfaces compatible.
1. Target Interface (Printer)
The interface that the client code expects.
C++
class Printer {
public:
virtual void print() = 0;
};
|
2. Adaptee (LegacyPrinter)
The existing class with an incompatible interface.
C++
class LegacyPrinter {
public:
void printDocument() {
std::cout << "Legacy Printer is printing a document." << std::endl;
}
};
|
3. Adapter (PrinterAdapter)
The class that adapts the LegacyPrinter to the Printer interface.
C++
class PrinterAdapter : public Printer {
private:
LegacyPrinter legacyPrinter;
public:
void print() override {
legacyPrinter.printDocument();
}
};
|
4. Client Code
The code that interacts with the Printer interface.
C++
void clientCode(Printer& printer) {
printer.print();
}
|
Complete Code for the above example:
C++
#include <iostream>
class Printer {
public:
virtual void print() = 0;
};
class LegacyPrinter {
public:
void printDocument() {
std::cout << "Legacy Printer is printing a document." << std::endl;
}
};
class PrinterAdapter : public Printer {
private:
LegacyPrinter legacyPrinter;
public:
void print() override {
legacyPrinter.printDocument();
}
};
void clientCode(Printer& printer) {
printer.print();
}
int main() {
PrinterAdapter adapter;
clientCode(adapter);
return 0;
}
|
Output
Legacy Printer is printing a document.
How Adapter Design Pattern works?
- Client Request:
- The client initiates a request by calling a method on the adapter using the target interface.
- Adapter Translation:
- The adapter translates or maps the client’s request into a form that the adaptee understands, using the adaptee’s interface.
- Adaptee Execution:
- The adaptee performs the actual work based on the translated request from the adapter.
- Result to Client:
- The client receives the results of the call, remaining unaware of the adapter’s presence or the specific details of the adaptee.
Why do we need Adapter Design Pattern?
- Integration of Existing Code:
- Scenario: When you have existing code or components with interfaces that are incompatible with the interfaces expected by new code or systems.
- Need: The Adapter pattern allows you to integrate existing components seamlessly into new systems without modifying their original code.
- Reuse of Existing Functionality:
- Scenario: When you want to reuse classes or components that provide valuable functionality but don’t conform to the desired interface.
- Need: The Adapter pattern enables you to reuse existing code by creating an adapter that makes it compatible with the interfaces expected by new code.
- Interoperability:
- Scenario: When you need to make different systems or components work together, especially when they have different interfaces.
- Need: The Adapter pattern acts as a bridge, allowing systems with incompatible interfaces to collaborate effectively.
- Client-Server Communication:
- Scenario: When building client-server applications, and the client expects a specific interface while the server provides a different one.
- Need: Adapters help in translating requests and responses between client and server, ensuring smooth communication despite interface differences.
- Third-Party Library Integration:
- Scenario: When incorporating third-party libraries or APIs into a project, and their interfaces do not match the rest of the system.
- Need: Adapters make it possible to use external components by providing a compatible interface for the rest of the application.
When not to use Adapter Design Pattern?
- When Interfaces Are Stable:
- Scenario: If the interfaces of the existing system and the new system are stable and not expected to change frequently.
- Reason: Adapters are most beneficial when dealing with evolving or incompatible interfaces. If the interfaces are stable, the overhead of maintaining adapters might outweigh the benefits.
- When Direct Modification Is Feasible:
- Scenario: If you have control over the source code of the existing system, and it’s feasible to directly modify its interface to match the target interface.
- Reason: If you can modify the existing code, direct adaptation of interfaces might be a simpler and more straightforward solution than introducing adapters.
- When Performance is Critical:
- Scenario: In performance-critical applications where the overhead introduced by the Adapter pattern is not acceptable.
- Reason: Adapters may introduce a level of indirection and abstraction, which could have a minor impact on performance. In situations where every bit of performance matters, the Adapter pattern might not be the best choice.
- When Multiple Adapters Are Required:
- Scenario: If a system requires numerous adapters for various components, and the complexity of managing these adapters becomes overwhelming.
- Reason: Managing a large number of adapters might lead to increased complexity and maintenance challenges. In such cases, reconsider the overall design or explore alternatives.
- When Adapters Introduce Ambiguity:
- Scenario: When introducing adapters leads to ambiguity or confusion in the overall system architecture.
- Reason: If the presence of adapters makes the system design less clear or harder to understand, it may be worthwhile to explore alternative solutions that offer a clearer design.
Like Article
Suggest improvement
Share your thoughts in the comments
Please Login to comment...