Bridging Incompatible C++ Logging Interfaces with the Adapter Pattern

You are a senior C++ developer maintaining a core business system that relies on a unified ILogger interface with methods log(const std::string&) and error(const std::string&). All modules—file, network, console—implement this interface, and the system registers ILogger* instances in a LoggerRegistry.

Problem: Incompatible Third‑Party Logger

A vendor provides a third‑party logger FastLogger with a different API: writeLog(const char* msg, int level). The method signatures and parameter types differ ( std::string vs const char*, separate log / error methods vs a unified level argument), making the library impossible to drop into the existing system directly.

Initial Attempt: Class Adapter

The first solution is to create a class that inherits both ILogger and FastLogger:

class LoggerAdapter : public ILogger, public FastLogger {
public:
    void log(const std::string& message) override {
        writeLog(message.c_str(), 0);
    }
    void error(const std::string& message) override {
        writeLog(message.c_str(), 1);
    }
};

This adapter can be registered as an ILogger and internally forwards calls to the FastLogger implementation. The approach works, but each new variant of the third‑party logger (e.g., HighPerfLogger, LowPowerLogger) requires a separate adapter class because inheritance is fixed at compile time.

Limitation of Class Adapter

When the vendor releases new logger subclasses, you must write a new adapter for each one, leading to code duplication and maintenance overhead.

Solution: Object Adapter (Composition)

Replace inheritance with composition: the adapter holds a pointer to the base FastLogger (or any of its subclasses) and forwards calls at runtime.

class LoggerAdapter : public ILogger {
private:
    FastLogger* adaptee_; // composition, can point to any FastLogger subclass
public:
    explicit LoggerAdapter(FastLogger* logger) : adaptee_(logger) {}
    void log(const std::string& message) override {
        adaptee_->writeLog(message.c_str(), 0);
    }
    void error(const std::string& message) override {
        adaptee_->writeLog(message.c_str(), 1);
    }
    void setAdaptee(FastLogger* logger) { adaptee_ = logger; }
};

Now a single LoggerAdapter can wrap FastLogger, HighPerfLogger, or LowPowerLogger instances:

LoggerAdapter* a1 = new LoggerAdapter(new FastLogger());
LoggerAdapter* a2 = new LoggerAdapter(new HighPerfLogger());
LoggerAdapter* a3 = new LoggerAdapter(new LowPowerLogger());
// Runtime switch
FastLogger* current = new HighPerfLogger();
LoggerAdapter* dynamicAdapter = new LoggerAdapter(current);
// Later switch to low‑power version
dynamicAdapter->setAdaptee(new LowPowerLogger());

Key Insight

Inheritance binds the adapter to a concrete class at compile time.

Composition lets the adapter hold a base‑class pointer, enabling it to work with any subclass at runtime.

This object‑adapter pattern eliminates the need for multiple adapter classes and provides a flexible bridge between incompatible interfaces.

Conclusion

By applying the Adapter design pattern with composition, you can integrate third‑party logging libraries without altering existing system code or the external library, and you gain the ability to switch implementations dynamically, reducing maintenance effort and preserving system flexibility.