In software development, writing code that works is only half the job. Writing code that is maintainable, scalable, and easy to understand is what sets great developers apart. This is exactly where the SOLID principles come in.

In this article, we’ll break down the SOLID principles one by one, explain them in simple terms, and look at examples (in C++) of how to apply them in real-world projects.

S — Single responsibility principle (SRP)
O — Open/closed principle (OCP)
L — Liskov Substitution principle (LSP)
I — Interface segregation principle (ISP)
D — Dependency inversion principle (DIP)

Single Responsibility Principle
A class should have only one reason to change.

#include <iostream>
#include <string>
using namespace std;

class Order {
private:
    string productName;
    int quantity;
    double price;

public:
    Order(string p, int q, double pr) : productName(p), quantity(q), price(pr) {}

    double calculateTotal() {
        return quantity * price;
    }

    void processPayment() {
        cout << "Processing payment of $" << calculateTotal() << " for " << productName << endl;
    }

    void generateInvoice() {
        cout << "Invoice: " << productName << " x " << quantity 
             << " = $" << calculateTotal() << endl;
    }
};

Here, the Order class is doing multiple things:
1. Business logic → calculating total price.
2. Payment processing → handling transactions.
3. Presentation → generating invoice.

If payment gateway changes → edit this class.
If invoice format changes → edit this class.
If pricing rules change → edit this class.
This is a violation of SRP, as there as multiple reasons to edit the class.
Instead, we can design as below

#include <iostream>
#include <string>
using namespace std;

// Holds order data only
class Order {
private:
    string productName;
    int quantity;
    double price;

public:
    Order(string p, int q, double pr) : productName(p), quantity(q), price(pr) {}

    string getProductName() const { return productName; }
    int getQuantity() const { return quantity; }
    double getPrice() const { return price; }
};

// Handles order calculations
class OrderCalculator {
public:
    double calculateTotal(const Order& order) {
        return order.getQuantity() * order.getPrice();
    }
};

// Handles payment processing
class PaymentProcessor {
public:
    void processPayment(const Order& order, double total) {
        cout << "Processing payment of Rs." << total 
             << " for " << order.getProductName() << endl;
    }
};

// Handles invoice generation
class InvoiceGenerator {
public:
    void generateInvoice(const Order& order, double total) {
        cout << "Invoice: " << order.getProductName() << " x " 
             << order.getQuantity() << " = Rs." << total << endl;
    }
};

Why is this better?
Order → only stores data.
OrderCalculator → calculates totals.
PaymentProcessor → processes payments.
InvoiceGenerator → generates invoices.
Now, one class = one responsibility, making the system flexible, maintainable, and easier to test.

Open/Closed Principle
Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
In simple terms, you should be able to add new functionality without modifying the existing code.
Why? Because modifying existing code can introduce bugs, break tested functionality, and increase maintenance cost.

#include <iostream>
using namespace std;

class Order {
public:
    double price;
    Order(double p) : price(p) {}
};

class Discount {
public:
    double calculateDiscount(Order& order, string type) {
        if (type == "SALE") {
            return order.price * 0.1;  // 10% discount
        } else if (type == "VIP") {
            return order.price * 0.2;  // 20% discount
        }
        return 0;
    }
};

int main() {
    Order order(100);
    Discount discount;
    cout << "Discount: Rs." << discount.calculateDiscount(order, "VIP") << endl;
}

Why this violates OCP?
- Every time you add a new discount type, you must modify the Discount class.
- Existing code changes → risk of breaking tested functionality.

#include <iostream>
using namespace std;

class Order {
public:
    double price;
    Order(double p) : price(p) {}
};

// Abstract base class (open for extension)
class Discount {
public:
    virtual double calculate(Order& order) = 0; // pure virtual
};

// New discount types extend the base class
class SaleDiscount : public Discount {
public:
    double calculate(Order& order) override {
        return order.price * 0.1;  // 10% discount
    }
};

class VIPDiscount : public Discount {
public:
    double calculate(Order& order) override {
        return order.price * 0.2;  // 20% discount
    }
};

int main() {
    Order order(100);

    Discount* discount1 = new SaleDiscount();
    cout << "Sale Discount: Rs." << discount1->calculate(order) << endl;

    Discount* discount2 = new VIPDiscount();
    cout << "VIP Discount: Rs." << discount2->calculate(order) << endl;
}

Why this follows OCP?
- Discount class is closed for modification.
- You can add new discount types (e.g., BlackFridayDiscount) by creating a new class that inherits from Discount.
- Existing classes (SaleDiscount, VIPDiscount) don’t need to change.

Liskov Substitution Principle
Objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program.
In simple terms:
- Subclasses should behave in ways that don’t break the expectations set by the parent class.
- You should be able to use a subclass anywhere the base class is expected.

#include <iostream>
using namespace std;

class Payment {
public:
    virtual void pay(double amount) {
        cout << "Paying Rs." << amount << " using generic payment." << endl;
    }
};

class CreditCardPayment : public Payment {
public:
    void pay(double amount) override {
        cout << "Paying Rs." << amount << " using Credit Card." << endl;
    }
};

// Problematic subclass
class FreeCouponPayment : public Payment {
public:
    void pay(double amount) override {
        if (amount > 0) {
            cout << "Cannot pay using free coupon for Rs." << amount << endl;
        }
    }
};

void processPayment(Payment* payment, double amount) {
    payment->pay(amount);
}

int main() {
    Payment* payment1 = new CreditCardPayment();
    processPayment(payment1, 500);  // Works fine

    Payment* payment2 = new FreeCouponPayment();
    processPayment(payment2, 500);  // Breaks expectations
}

Why this violates LSP?
- processPayment expects any Payment to handle the amount.
- FreeCouponPayment cannot handle amounts > 0 properly → breaks the contract of the base class.
- Substituting Payment* with FreeCouponPayment* causes unexpected behavior.

#include <iostream>
using namespace std;

class Payment {
public:
    virtual void pay(double amount) = 0; // pure virtual
};

class CreditCardPayment : public Payment {
public:
    void pay(double amount) override {
        cout << "Paying Rs." << amount << " using Credit Card." << endl;
    }
};

class PayPalPayment : public Payment {
public:
    void pay(double amount) override {
        cout << "Paying Rs." << amount << " using PayPal." << endl;
    }
};

// FreeCoupon only allows 0 amount
class FreeCouponPayment : public Payment {
public:
    void pay(double amount) override {
        if (amount == 0)
            cout << "Using free coupon, amount Rs." << amount << endl;
        else
            cout << "Invalid: Free coupon cannot pay Rs." << amount << endl;
    }
};

void processPayment(Payment* payment, double amount) {
    payment->pay(amount);
}

int main() {
    Payment* payment1 = new CreditCardPayment();
    processPayment(payment1, 500);

    Payment* payment2 = new PayPalPayment();
    processPayment(payment2, 800);

    Payment* payment3 = new FreeCouponPayment();
    processPayment(payment3, 0);  // Works as expected
}

Here,
- Every subclass can replace the base class without breaking expectations.
- processPayment works correctly for all Payment objects.
- Contract of the base class (pay) is respected.
LSP ensures your subclasses are true “substitutes” for their parent class. Violating LSP often leads to unexpected behavior and bugs in polymorphic code.

Interface Segregation Principle
Clients should not be forced to depend on interfaces they do not use.
A client is any class, function, or module that calls methods or accesses functionality of another class/interface.
In simple terms:
- Instead of creating a large, bloated interface, break it into smaller, specific interfaces.
- Classes should implement only the methods they actually need.

#include <iostream>
using namespace std;

class ECommerceMachine {
public:
    virtual void buyProduct() = 0;
    virtual void returnProduct() = 0;
    virtual void giftProduct() = 0;  // Not every machine supports this
};

class SimpleStore : public ECommerceMachine {
public:
    void buyProduct() override {
        cout << "Buying product..." << endl;
    }

    void returnProduct() override {
        cout << "Returning product..." << endl;
    }

    void giftProduct() override {
        // Problem: SimpleStore cannot gift, but forced to implement
        cout << "Cannot gift product!" << endl;
    }
};

Here,
- SimpleStore is forced to implement giftProduct() even though it doesn’t support it.
- Large interfaces → unnecessary implementations, more maintenance, potential bugs.

Instead, we split the interface into smaller, focused interfaces:

#include <iostream>
using namespace std;

// Core buying interface
class Buyable {
public:
    virtual void buyProduct() = 0;
};

// Optional return interface
class Returnable {
public:
    virtual void returnProduct() = 0;
};

// Optional gift interface
class Giftable {
public:
    virtual void giftProduct() = 0;
};

// Simple store only supports buying and returning
class SimpleStore : public Buyable, public Returnable {
public:
    void buyProduct() override {
        cout << "Buying product..." << endl;
    }

    void returnProduct() override {
        cout << "Returning product..." << endl;
    }
};

// Premium store supports all actions
class PremiumStore : public Buyable, public Returnable, public Giftable {
public:
    void buyProduct() override {
        cout << "Buying product..." << endl;
    }

    void returnProduct() override {
        cout << "Returning product..." << endl;
    }

    void giftProduct() override {
        cout << "Gifting product..." << endl;
    }
};

So,
- Each class implements only the interfaces it needs.
- No unnecessary methods → easier to maintain, fewer bugs.
- Clients are not forced to depend on functionality they don’t use.

Dependency Inversion Principle
High-level modules should not depend on low-level modules. Both should depend on abstractions (interfaces). Abstractions should not depend on details. Details should depend on abstractions.

In simple terms,
- Don’t make your high-level code depend on concrete implementations.
- Depend on interfaces or abstract classes so you can change low-level details without touching high-level logic.

Consider an order notification system:

#include <iostream>
using namespace std;

// Low-level module
class EmailService {
public:
    void sendEmail(string message) {
        cout << "Sending email: " << message << endl;
    }
};

// High-level module
class OrderProcessor {
private:
    EmailService emailService;  // Direct dependency
public:
    void processOrder() {
        cout << "Processing order..." << endl;
        emailService.sendEmail("Order processed successfully");
    }
};

int main() {
    OrderProcessor processor;
    processor.processOrder();
}

Here,
- OrderProcessor (high-level) depends directly on EmailService (low-level).
- What if we want to send SMS instead? Or push notification?
- We’d have to modify OrderProcessor, which is bad.

Instead, we introduce abstraction (interface) for notifications:

#include <iostream>
using namespace std;

// Abstraction
class INotifier {
public:
    virtual void notify(string message) = 0;
};

// Low-level module 1
class EmailNotifier : public INotifier {
public:
    void notify(string message) override {
        cout << "Sending email: " << message << endl;
    }
};

// Low-level module 2
class SMSNotifier : public INotifier {
public:
    void notify(string message) override {
        cout << "Sending SMS: " << message << endl;
    }
};

// High-level module depends on abstraction
class OrderProcessor {
private:
    INotifier* notifier;  // depends on interface
public:
    OrderProcessor(INotifier* n) : notifier(n) {}

    void processOrder() {
        cout << "Processing order..." << endl;
        notifier->notify("Order processed successfully");
    }
};

int main() {
    INotifier* emailNotifier = new EmailNotifier();
    OrderProcessor processor1(emailNotifier);
    processor1.processOrder();

    INotifier* smsNotifier = new SMSNotifier();
    OrderProcessor processor2(smsNotifier);
    processor2.processOrder();
}

Now,
- OrderProcessor (high-level) depends only on the abstraction INotifier.
- You can now add new notification types (push, WhatsApp, etc.) without changing OrderProcessor.
- Low-level modules (EmailNotifier, SMSNotifier) depend on the same abstraction.

DIP decouples high-level logic from low-level implementation, making your code flexible, testable, and easy to extend.

Next time you design a class, ask yourself — is it SOLID?