Mastering SOLID in C++

The 5 commandments of clean, maintainable object-oriented design.

psychology Why SOLID?

SOLID principles help software engineers write code that is easy to maintain, understand, and extend. In C++, where memory management and inheritance complexities abound, adhering to these rules prevents "spaghetti code" and reduces technical debt.

code How to use this app

Select a principle from the sidebar to dive deep. You'll see visual analogies, clear definitions, and interactive Bad vs Good code comparisons.

Single Responsibility Principle

"A class should have one, and only one, reason to change."

Problem: The User class handles data, database operations, AND email formatting. Changing the DB or email logic requires changing the User class.

class User {
public:
    User(string name, string email) : name(name), email(email) {}

    // Responsibility 1: Logic
    void promote() {
        // promote logic...
    }

    // Responsibility 2: Persistence (Violation)
    void saveToDatabase() {
        // SQL connection code...
        // insert into users...
    }

    // Responsibility 3: Notification (Violation)
    void sendWelcomeEmail() {
        // SMTP connection code...
        // html formatting...
    }

private:
    string name;
    string email;
};

Solution: Split responsibilities into UserRepository (DB) and EmailService (Notification). The User class stays pure.

// 1. Data Model
class User {
public:
    string getName() const { return name; }
    string getEmail() const { return email; }
private:
    string name;
    string email;
};

// 2. Persistence Responsibility
class UserRepository {
public:
    void save(const User& user) {
        // SQL code specific to saving user
    }
};

// 3. Notification Responsibility
class EmailService {
public:
    void sendWelcomeEmail(const User& user) {
        // Email logic here
    }
};

// Usage
void registerUser(User u) {
    UserRepository repo;
    EmailService emailer;
    
    repo.save(u);
    emailer.sendWelcomeEmail(u);
}

Open/Closed Principle

"Software entities should be open for extension, but closed for modification."

Problem: To add a 'Triangle', we must modify the AreaCalculator class and add a new else if. This risks breaking existing logic.

enum ShapeType { CIRCLE, RECTANGLE };

class Shape {
public:
    ShapeType type;
};

class Circle : public Shape {
public:
    double radius;
    Circle() { type = CIRCLE; }
};

class Rectangle : public Shape {
public:
    double width, height;
    Rectangle() { type = RECTANGLE; }
};

class AreaCalculator {
public:
    double calculateArea(Shape* shape) {
        if (shape->type == CIRCLE) {
            Circle* c = static_cast(shape);
            return 3.14 * c->radius * c->radius;
        } 
        else if (shape->type == RECTANGLE) {
            Rectangle* r = static_cast(shape);
            return r->width * r->height;
        }
        // MODIFY HERE for Triangle? Bad!
        return 0;
    }
};

Solution: Use Polymorphism. Shape defines a contract. New shapes implement it. AreaCalculator never needs to change.

class Shape {
public:
    virtual double area() const = 0; // Contract
    virtual ~Shape() {}
};

class Circle : public Shape {
    double radius;
public:
    Circle(double r) : radius(r) {}
    double area() const override {
        return 3.14 * radius * radius;
    }
};

class Rectangle : public Shape {
    double width, height;
public:
    Rectangle(double w, double h) : width(w), height(h) {}
    double area() const override {
        return width * height;
    }
};

// Extension: Just add a new class!
class Triangle : public Shape {
    // ... impl
};

class AreaCalculator {
public:
    // Closed for modification
    double calculate(const Shape& shape) {
        return shape.area();
    }
};

Liskov Substitution Principle

"Subtypes must be substitutable for their base types."

Problem: The Classic Square/Rectangle problem. A Square IS-A Rectangle in geometry, but not in behavior. Setting width on a Square changes its height, violating the Rectangle's behavior expectations.

class Rectangle {
protected:
    int width, height;
public:
    virtual void setWidth(int w) { width = w; }
    virtual void setHeight(int h) { height = h; }
    int getArea() { return width * height; }
};

class Square : public Rectangle {
public:
    // This violates LSP! 
    // Changing width unexpectedly changes height.
    void setWidth(int w) override {
        width = w;
        height = w;
    }
    void setHeight(int h) override {
        width = h;
        height = h;
    }
};

void process(Rectangle& r) {
    r.setWidth(5);
    r.setHeight(4);
    // Expectation: 5 * 4 = 20
    // Reality if r is Square: 4 * 4 = 16
    assert(r.getArea() == 20); // FAILS for Square
}

Solution: Separate the hierarchy. Square and Rectangle are both Shapes, but one does not inherit the other's *implementation* details like setWidth/setHeight.

class Shape {
public:
    virtual int getArea() = 0;
};

class Rectangle : public Shape {
    int width, height;
public:
    Rectangle(int w, int h) : width(w), height(h) {}
    void setWidth(int w) { width = w; }
    void setHeight(int h) { height = h; }
    int getArea() override { return width * height; }
};

class Square : public Shape {
    int size;
public:
    Square(int s) : size(s) {}
    void setSize(int s) { size = s; }
    int getArea() override { return size * size; }
};

// Now process() cannot make wrong assumptions
void printArea(Shape& s) {
    cout << "Area: " << s.getArea() << endl; // Works for both
}

Interface Segregation Principle

"Clients should not be forced to depend on interfaces they do not use."

Problem: IMachine forces a SimplePrinter to implement scan() and fax() even if it can't. This leads to empty methods or runtime errors.

struct IMachine {
    virtual void print() = 0;
    virtual void scan() = 0;
    virtual void fax() = 0;
};

class MultiFunctionPrinter : public IMachine {
public:
    void print() override { /* ... */ }
    void scan() override { /* ... */ }
    void fax() override { /* ... */ }
};

class SimplePrinter : public IMachine {
public:
    void print() override { /* ... */ }
    
    // Forced to implement methods I don't need!
    void scan() override { 
        throw runtime_error("Not supported"); 
    }
    void fax() override { 
        throw runtime_error("Not supported"); 
    }
};

Solution: Break the big interface into smaller, specific ones (IPrinter, IScanner). Classes implement only what they need.

struct IPrinter {
    virtual void print() = 0;
};

struct IScanner {
    virtual void scan() = 0;
};

struct IFax {
    virtual void fax() = 0;
};

// Implement all for advanced machine
class MFP : public IPrinter, public IScanner, public IFax {
public:
    void print() override { /*...*/ }
    void scan() override { /*...*/ }
    void fax() override { /*...*/ }
};

// Only implement what is needed
class SimplePrinter : public IPrinter {
public:
    void print() override { /*...*/ }
};

Dependency Inversion Principle

"Depend on abstractions, not on concretions."

Problem: The high-level Switch class directly depends on the low-level LightBulb class. If we want to switch a Fan, we must rewrite the Switch class.

class LightBulb {
public:
    void turnOn() { cout << "Light on"; }
    void turnOff() { cout << "Light off"; }
};

class Switch {
    LightBulb bulb; // Direct Dependency!
public:
    void toggle(bool on) {
        if (on) bulb.turnOn();
        else bulb.turnOff();
    }
};

Solution: Introduce an interface ISwitchable. The Switch depends on the interface. LightBulb implements the interface. Decoupled!

// Abstraction
struct ISwitchable {
    virtual void turnOn() = 0;
    virtual void turnOff() = 0;
    virtual ~ISwitchable() {}
};

// Low-level module depends on Abstraction
class LightBulb : public ISwitchable {
public:
    void turnOn() override { cout << "Light on"; }
    void turnOff() override { cout << "Light off"; }
};

class Fan : public ISwitchable {
public:
    void turnOn() override { cout << "Fan spinning"; }
    void turnOff() override { cout << "Fan stopped"; }
};

// High-level module depends on Abstraction
class Switch {
    ISwitchable& device;
public:
    Switch(ISwitchable& d) : device(d) {}
    
    void toggle(bool on) {
        if (on) device.turnOn();
        else device.turnOff();
    }
};

SOLID C++