Interface Breakdown in C++: Enhancing Maintainability and Testability with Abstract Classes

Introduction

We made it! The last lesson in the course! In our previous lessons, we explored various types of seams, including functional seams with functions as parameters and feature flags, as well as object seams using inheritance. These techniques have equipped us with the tools to modify and extend code without altering its original structure. In this lesson, we will focus on using interface breakdown to create object seams, a powerful method for enhancing code maintainability and testability. By the end of this lesson, we'll understand how to refactor large interfaces into smaller, more focused ones, improving the clarity and flexibility of our code.

Challenges with Large Interfaces

Large interfaces in C++ can be particularly problematic due to the language's strong typing and the need for explicit method implementations. When a class inherits from a large interface, it is required to implement all pure virtual methods, even if some of those methods are irrelevant to its specific functionality. This can lead to bloated and complex class definitions, where developers are forced to either implement placeholder methods (e.g., throwing std::logic_error or returning default values) or leave them as no-ops. Such practices not only clutter the code but also introduce potential sources of bugs and unexpected behaviors during testing. Additionally, large interfaces can increase coupling between classes, making the codebase harder to maintain and extend. By adhering to the interface segregation principle, we can mitigate these issues by breaking down large interfaces into smaller, more focused ones, ensuring that each class only implements the methods it truly needs.

Interface Segregation Principle (ISP)

The interface segregation principle (ISP) is a key concept in software design that addresses the issues associated with large interfaces. In C++, ISP advocates for creating smaller, more focused abstract classes (interfaces) that only include pure virtual methods relevant to a specific role. This approach ensures that derived classes only implement the methods they actually need, resulting in cleaner and more maintainable code. By adhering to ISP, we can create modular code that is easier to test and extend, leveraging C++'s support for multiple inheritance to combine these smaller interfaces as needed.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Implementing Interface Breakdown

Let's explore how to implement interface breakdown using a practical example in C++. Initially, both the CreditCardService class and the PayPalPaymentService class implement the IPaymentService interface using abstract classes with pure virtual functions:

C++

#include <iostream>
#include <stdexcept>

class IPaymentService {
public:
    virtual void ProcessPayment(double amount) = 0;
    virtual std::string GenerateReport() = 0;
    virtual ~IPaymentService() = default;
};

class CreditCardService : public IPaymentService {
public:
    void ProcessPayment(double amount) override {
        std::cout << "Processing credit card payment: " << amount << std::endl;
    }

    std::string GenerateReport() override {
        return "Credit card report generated.";
    }
};

class PayPalPaymentService : public IPaymentService {
public:
    void ProcessPayment(double amount) override {
        std::cout << "Processing simple payment: " << amount << std::endl;
    }

    std::string GenerateReport() override {
        throw std::logic_error("Report generation is not supported.");
    }
};

#include <iostream>
#include <stdexcept>

class IPaymentService {
public:
    virtual void ProcessPayment(double amount) = 0;
    virtual std::string GenerateReport() = 0;
    virtual ~IPaymentService() = default;
};

class CreditCardService : public IPaymentService {
public:
    void ProcessPayment(double amount) override {
        std::cout << "Processing credit card payment: " << amount << std::endl;
    }

    std::string GenerateReport() override {
        return "Credit card report generated.";
    }
};

class PayPalPaymentService : public IPaymentService {
public:
    void ProcessPayment(double amount) override {
        std::cout << "Processing simple payment: " << amount << std::endl;
    }

    std::string GenerateReport() override {
        throw std::logic_error("Report generation is not supported.");
    }
};

We can see that the PayPalPaymentService doesn't actually generate reports. Maybe the reports are obtained from a web service offered by PayPal or something similar. The point is that report generation isn't supported in that particular class.

Let's look at how we can refactor the interface into smaller, more focused interfaces:

C++

class IPaymentProcessor {
public:
    virtual void ProcessPayment(double amount) = 0;
    virtual ~IPaymentProcessor() = default;
};

class IReportGenerator {
public:
    virtual std::string GenerateReport() = 0;
    virtual ~IReportGenerator() = default;
};

class IPaymentProcessor {
public:
    virtual void ProcessPayment(double amount) = 0;
    virtual ~IPaymentProcessor() = default;
};

class IReportGenerator {
public:
    virtual std::string GenerateReport() = 0;
    virtual ~IReportGenerator() = default;
};

After refactoring, the CreditCardService class implements both smaller interfaces, while the PayPalPaymentService class implements only the IPaymentProcessor:

C++

class CreditCardService : public IPaymentProcessor, public IReportGenerator {
public:
    void ProcessPayment(double amount) override {
        std::cout << "Processing credit card payment: " << amount << std::endl;
    }

    std::string GenerateReport() override {
        return "Credit card report generated.";
    }
};

class SimplePaymentService : public IPaymentProcessor {
public:
    void ProcessPayment(double amount) override {
        std::cout << "Processing simple payment: " << amount << std::endl;
    }
};

class CreditCardService : public IPaymentProcessor, public IReportGenerator {
public:
    void ProcessPayment(double amount) override {
        std::cout << "Processing credit card payment: " << amount << std::endl;
    }

    std::string GenerateReport() override {
        return "Credit card report generated.";
    }
};

class SimplePaymentService : public IPaymentProcessor {
public:
    void ProcessPayment(double amount) override {
        std::cout << "Processing simple payment: " << amount << std::endl;
    }
};