Skip to Content
šŸ‘† We offer 1-on-1 classes as well check now

Adapter Pattern

The Adapter pattern is a structural design pattern that allows incompatible interfaces to work together. It acts as a bridge between two existing interfaces, allowing them to interact without modifying their source code. This pattern is particularly useful when you want to use an existing class but its interface doesnā€™t match the one you need.

What is Adapter Pattern

The Adapter pattern revolves around the concept of wrapping an object with a different interface to make it compatible with a client that expects a specific interface. It allows you to reuse existing classes that might not have been designed to work together originally. This is achieved through one of two primary approaches:

  • Object Adapter: Uses composition. The adapter contains an instance of the class it adapts and delegates calls to it. This is the more common and generally preferred approach as it promotes loose coupling.

  • Class Adapter: Uses multiple inheritance. The adapter inherits from both the interface and the class it adapts. While simpler in some cases, this approach is less flexible because it relies on inheritance and can lead to the ā€œfragile base classā€ problem. It is generally discouraged in modern C++ due to the complexities of multiple inheritance.

In-depth Explanations:

The Adapter pattern addresses the problem of interface incompatibility. Imagine you have a legacy system that provides data in a specific format, but your new application expects a different format. Instead of rewriting the legacy system or modifying your application, you can use an Adapter to translate the data.

Edge Cases:

  • Complex Adaptees: Adapting very complex classes with numerous methods can lead to a large and complex adapter class. Consider breaking down the adaptation into smaller, more manageable adapters, or refactoring the adaptee if possible.
  • Performance: Adapting interfaces introduces a layer of indirection, which can have a slight performance impact. This is usually negligible, but in performance-critical applications, itā€™s important to profile your code to ensure the adapter isnā€™t a bottleneck. The object adapter approach generally has a small performance overhead compared to direct calls to the adaptee.
  • Adapting Immutable Objects: If the adaptee is immutable (its state cannot be changed after creation), the adapter might need to create a copy of the adapteeā€™s data and modify the copy to conform to the target interface.

Performance Considerations:

The Adapter pattern introduces a level of indirection, which can potentially impact performance. However, the impact is usually minimal and often outweighed by the benefits of code reuse and flexibility. When performance is critical, consider the following:

  • Minimize Adapter Complexity: Keep the adapter class as simple as possible to reduce overhead.
  • Caching: If the adapter performs expensive computations, consider caching the results to avoid recomputation.
  • Profiling: Use profiling tools to identify any performance bottlenecks introduced by the adapter.

Syntax and Usage

The Adapter pattern typically involves the following components:

  • Target Interface: The interface that the client expects.
  • Adaptee: The existing class that needs to be adapted.
  • Adapter: The class that implements the Target Interface and adapts the Adaptee.
// Target Interface
class Target {
public:
    virtual ~Target() = default;
    virtual std::string request() = 0;
};
 
// Adaptee
class Adaptee {
public:
    std::string specificRequest() {
        return ".eetpadA eht fo tseuqer cificeps ehT"; // The Specific Request of the Adaptee
    }
};
 
// Adapter (Object Adapter)
class Adapter : public Target {
private:
    Adaptee m_adaptee; // Composition
 
public:
    Adapter(Adaptee adaptee) : m_adaptee(adaptee) {}
 
    std::string request() override {
        std::string reversedString = m_adaptee.specificRequest();
        std::reverse(reversedString.begin(), reversedString.end());
        return reversedString;
    }
};
 
// Client Code
int main() {
    Adaptee adaptee;
    Adapter adapter(adaptee);
 
    std::cout << adapter.request() << std::endl; // Output: The Specific Request of the Adaptee
    return 0;
}

Basic Example

Letā€™s consider a scenario where you have a legacy logging system that uses a specific logging interface. You want to integrate this logging system with a new application that expects a different logging interface.

#include <iostream>
#include <string>
#include <fstream>
 
// Legacy Logging Interface (Adaptee)
class LegacyLogger {
public:
    void logMessage(const std::string& message) {
        std::ofstream logFile("legacy_log.txt", std::ios::app);
        if (logFile.is_open()) {
            logFile << "Legacy Log: " << message << std::endl;
            logFile.close();
        } else {
            std::cerr << "Error: Could not open legacy log file." << std::endl;
        }
    }
};
 
// Modern Logging Interface (Target)
class ILogger {
public:
    virtual ~ILogger() = default;
    virtual void log(const std::string& message) = 0;
};
 
// Adapter
class LoggerAdapter : public ILogger {
private:
    LegacyLogger legacyLogger;
 
public:
    void log(const std::string& message) override {
        legacyLogger.logMessage(message);
    }
};
 
// Client Code
int main() {
    LoggerAdapter adapter;
    adapter.log("This is a message logged using the adapter.");
 
    return 0;
}

Explanation:

  • The LegacyLogger represents the existing logging system with its specific logMessage method.
  • The ILogger is the target interface that the new application expects, with a log method.
  • The LoggerAdapter implements the ILogger interface and uses a LegacyLogger instance to perform the actual logging. This allows the new application to log messages using the ILogger interface, while the adapter translates these calls to the LegacyLogger.

Advanced Example

Consider a scenario where you need to integrate a third-party image processing library that uses a different image format than your application.

#include <iostream>
#include <string>
#include <vector>
 
// Third-Party Image Library (Adaptee) - Simplified
class ThirdPartyImage {
public:
    ThirdPartyImage(int width, int height, const std::vector<int>& data) : m_width(width), m_height(height), m_data(data) {}
 
    int getWidth() const { return m_width; }
    int getHeight() const { return m_height; }
    const std::vector<int>& getImageData() const { return m_data; }
 
private:
    int m_width;
    int m_height;
    std::vector<int> m_data;  // Assume integer-based pixel data
};
 
// Application's Image Interface (Target)
class IImage {
public:
    virtual ~IImage() = default;
    virtual int getWidth() const = 0;
    virtual int getHeight() const = 0;
    virtual std::vector<unsigned char> getPixelData() const = 0; // Expects unsigned char
};
 
// Adapter
class ImageAdapter : public IImage {
private:
    ThirdPartyImage m_thirdPartyImage;
 
public:
    ImageAdapter(const ThirdPartyImage& image) : m_thirdPartyImage(image) {}
 
    int getWidth() const override {
        return m_thirdPartyImage.getWidth();
    }
 
    int getHeight() const override {
        return m_thirdPartyImage.getHeight();
    }
 
    std::vector<unsigned char> getPixelData() const override {
        const std::vector<int>& intData = m_thirdPartyImage.getImageData();
        std::vector<unsigned char> charData(intData.size());
        for (size_t i = 0; i < intData.size(); ++i) {
            charData[i] = static_cast<unsigned char>(intData[i]); // Convert int to unsigned char
        }
        return charData;
    }
};
 
// Client Code
int main() {
    std::vector<int> imageData = {100, 150, 200, 50, 255, 0}; // Example data
    ThirdPartyImage thirdPartyImage(2, 3, imageData); // 2x3 image
 
    ImageAdapter adapter(thirdPartyImage);
 
    std::cout << "Width: " << adapter.getWidth() << std::endl;
    std::cout << "Height: " << adapter.getHeight() << std::endl;
 
    std::vector<unsigned char> pixelData = adapter.getPixelData();
    std::cout << "Pixel Data (as unsigned char): ";
    for (unsigned char pixel : pixelData) {
        std::cout << static_cast<int>(pixel) << " "; // Cast back to int for printing
    }
    std::cout << std::endl;
 
    return 0;
}

Explanation:

  • The ThirdPartyImage represents the image format used by the third-party library (using int for pixel data).
  • The IImage is the interface that the application expects (using unsigned char for pixel data).
  • The ImageAdapter adapts the ThirdPartyImage to the IImage interface by converting the pixel data from int to unsigned char.

Common Use Cases

  • Integrating Legacy Systems: Adapting legacy code to work with modern applications.
  • Using Third-Party Libraries: Integrating libraries with incompatible interfaces.
  • Refactoring: Adapting existing code to a new interface during refactoring.
  • Data Conversion: Converting data from one format to another.

Best Practices

  • Favor Object Adapter over Class Adapter: Object adapter promotes loose coupling and is more flexible.
  • Keep Adapters Simple: Avoid adding unnecessary complexity to the adapter class.
  • Document the Adapterā€™s Purpose: Clearly document why the adapter is needed and what it adapts.
  • Consider Performance Implications: Profile your code if performance is critical.
  • Test Thoroughly: Ensure the adapter correctly translates between the interfaces.

Common Pitfalls

  • Over-Complicating the Adapter: Adding unnecessary logic or functionality to the adapter. The adapter should primarily focus on interface conversion.
  • Tight Coupling: Creating adapters that are tightly coupled to the adaptee, making it difficult to change the adaptee in the future.
  • Ignoring Error Handling: Failing to handle errors that may occur during the adaptation process.
  • Not Following the Liskov Substitution Principle: Ensuring the adapter behaves consistently with the target interface.

Key Takeaways

  • The Adapter pattern allows incompatible interfaces to work together.
  • It promotes code reuse and flexibility.
  • Object adapter is generally preferred over class adapter.
  • Keep adapters simple and well-documented.
  • Consider performance implications and test thoroughly.
Last updated on