Liskov Substitution Principle (LSP)

The Liskov Substitution Principle is one of the SOLID principles of object-oriented programming. It was introduced by Barbara Liskov in 1987 and it states:

“Objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program.”

What It Really Means:

Imagine you’re working with a class called Bird that has a method fly(). If you create a subclass Penguin from Bird, but Penguin can’t fly, then substituting Bird with Penguin could break your program. That’s a violation of LSP.

The principle pushes us to design subclasses that truly behave like their parent class, so code that uses the base class doesn’t have to worry about the specific subclass being used.

LSP in Action (Simple Example):

class Bird {
public:
    virtual void fly() {
        std::cout << "Flying..." << std::endl;
    }
};

class Sparrow : public Bird {
public:
    void fly() override {
        std::cout << "Sparrow flying!" << std::endl;
    }
};

// This class violates LSP
class Ostrich : public Bird {
public:
    void fly() override {
        throw std::logic_error("Ostriches can't fly!");
    }
};

In the example above, Ostrich breaks LSP because it can’t perform the fly() behavior expected from Bird.

Why It Matters:

• Encourages safe inheritance.
• Makes code more reliable and maintainable.
• Helps avoid unexpected runtime errors.
• Ensures that your class hierarchy makes logical sense.

How to Stick to LSP:

• Don’t override methods in a way that changes their expected behavior.
• Use composition over inheritance if subclass behavior doesn’t match the base class.
• Clearly define contracts (what methods are supposed to do) and ensure subclasses respect them.

What is LSP?

Definition by Barbara Liskov:

If S is a subtype of T, then objects of type T may be replaced with objects of type S without altering the correctness of the program.

Simple Version:

A subclass should be able to stand in for its parent class without breaking the program.

What does that mean?

Let’s break it down:

• You create a base class (Parent class).
• Then you make a derived class (Child class).
• The child should behave in a way that’s expected from the parent.
• You should be able to use the child wherever you used the parent, and things should just work.

Real-Life Analogy

Let’s say:

• You have a class “Bird” with a method fly().
• You create a subclass “Parrot” — fine, it can fly.
• Now you create a subclass “Penguin” — 🐧 uh-oh! Penguins can’t fly.

If you call fly() on a Penguin object assuming it’s a Bird, your program breaks the expectation.

🚫 That violates LSP!

Example in C++ that Violates LSP

class Bird {
public:
    virtual void fly() {
        cout << "Flying..." << endl;
    }
};

class Sparrow : public Bird {
public:
    void fly() override {
        cout << "Sparrow flying" << endl;
    }
};

class Ostrich : public Bird {
public:
    void fly() override {
        throw runtime_error("Ostriches can't fly!");
    }
};

Problem:

• If someone uses Bird* b = new Ostrich(); b->fly(); expecting it to fly — it crashes.
• Ostrich is a Bird, but it doesn’t behave like a Bird should.

This violates LSP.

LSP-Compliant Design

Solution: Refactor your classes to respect behavior expectations.

class Bird {
public:
    virtual void eat() {
        cout << "Bird eating" << endl;
    }
};

class FlyingBird : public Bird {
public:
    virtual void fly() = 0;
};

class Sparrow : public FlyingBird {
public:
    void fly() override {
        cout << "Sparrow flying" << endl;
    }
};

class Ostrich : public Bird {
    // No fly() here
};

Now:

• Ostrich doesn’t pretend to be a flying bird.
• If your logic requires only flying birds, you use the FlyingBird type.
• LSP is safely respected.

LSP in Code: A Simple, Clear Example

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

protected:
    int width;
    int height;
};

Now we make a Square from Rectangle:

class Square : public Rectangle {
public:
    void setWidth(int w) override {
        width = height = w;
    }

    void setHeight(int h) override {
        width = height = h;
    }
};

Problem:

If someone does this:

Rectangle* r = new Square();
r->setWidth(5);
r->setHeight(10);
cout << r->getArea();  // Expected: 50, But it gives 100

Uh-oh! Because setting width or height sets both in Square.
This breaks expected behavior.
It violates LSP.

LSP-Compliant Refactor

Instead, don’t inherit Square from Rectangle directly if they behave differently.

Maybe use composition or separate hierarchy.

LSP Summary Table

Key Tips to Follow LSP

• Derived classes must honor contracts/behavior of base class.
• Don’t override methods in a way that changes expected behavior.
• Use interfaces or abstract classes to separate capabilities (like flying).
• Prefer composition over inheritance when behaviors differ.

Want to Try a LSP-based Mini Project?

We can build:

• A PaymentMethod base class (pay())
• Subclasses: CreditCard, UPI, Wallet
• And see how breaking or respecting LSP affects real logic

FAQ on Liskov Substitution Principle (LSP) in C++

1. What is the Liskov Substitution Principle (LSP) in C++?

The Liskov Substitution Principle (LSP) is one of the SOLID principles of object-oriented programming. It states that objects of a derived class should be replaceable with objects of their base class without affecting the correctness of the program. In simple terms, subclasses should behave like their parent classes without breaking functionality.

2. Why is the Liskov Substitution Principle important in software design?

LSP ensures code reliability, reusability, and maintainability. By following it, developers prevent unexpected behaviors when using inheritance. It reduces bugs, improves abstraction, and makes the system easier to extend in the future.

3. Can you give a simple C++ example of the Liskov Substitution Principle?

Yes.

#include <iostream>
using namespace std;

class Bird {
public:
    virtual void fly() { cout << "Bird can fly\n"; }
};

class Sparrow : public Bird {
public:
    void fly() override { cout << "Sparrow flying high\n"; }
};

// Substitution works correctly
int main() {
    Bird* b = new Sparrow();
    b->fly();  // Works fine as Sparrow behaves like Bird
    delete b;
    return 0;
}

Here, Sparrow can substitute Bird without breaking the program, which follows LSP.

4. What happens if LSP is violated in C++?

Violating LSP leads to runtime errors, unexpected behaviors, and poor code design. For example, if a derived class overrides a base class function in a way that changes its expected behavior, the system may produce wrong results or even crash.

5. How does the Liskov Substitution Principle relate to C++ design patterns?

Many C++ design patterns, such as Strategy, Template Method, and Factory Method, rely on LSP to ensure that subclasses can replace base classes seamlessly. Without LSP, these patterns lose their flexibility and correctness.

6. How can I check if my C++ code follows the Liskov Substitution Principle?

You can verify by asking:

• Can I replace every instance of the base class with the subclass?
• Does the subclass maintain the expected behavior of the parent?
  If the answer is yes, then your code follows LSP.

7. What are real-life examples of the Liskov Substitution Principle?

• Vehicles: A Car is a type of Vehicle and can be used wherever a Vehicle is expected.
• Shapes: A Circle should behave like a Shape without altering the expected behavior of a Shape class.
• Payment Systems: A CreditCardPayment should work wherever a generic PaymentMethod is required.

8. How does LSP improve C++ code quality?

• Promotes polymorphism
• Reduces tight coupling
• Makes code testable and scalable
• Encourages clean architecture with fewer bugs

9. What is the difference between LSP and the Open-Closed Principle (OCP)?

• LSP ensures that subclasses can replace base classes without breaking functionality.
• OCP ensures that classes are open for extension but closed for modification.
  Both are connected — violating LSP often means violating OCP as well.

10. How is Liskov Substitution Principle used in modern C++ projects in 2025?

In 2025 C++ development, LSP is applied in:

• Embedded systems for safe hardware abstraction
• Game development for character and object hierarchies
• Enterprise applications for scalable and maintainable architectures
• Design patterns to ensure flexible and reusable solutions

You can also Visit other tutorials of Embedded Prep 

• What is eMMC (Embedded MultiMediaCard) memory ?
• Top 30+ I2C Interview Questions
• Bit Manipulation Interview Questions
• Structure and Union in c
• Little Endian vs. Big Endian: A Complete Guide
• Merge sort algorithm

Special thanks to @mr-raj for contributing to this article on Embedded Prep

When writing clean and maintainable code, the Single Responsibility Principle (SRP) is one of the most important design principles to follow. It is the first principle in the SOLID design principles, which are a set of five rules that help developers write better object-oriented code.

In this article, you’ll learn:

• What the Single Responsibility Principle is
• Why it matters
• Real-world and code examples
• Benefits of using SRP
• Best practices to follow

What is the Single Responsibility Principle?

The Single Responsibility Principle (SRP) states:

“A class should have only one reason to change.“

This means that a class should do only one thing and should have only one responsibility. In other words, it should only focus on one task or job.

If a class is doing multiple unrelated tasks, then it violates SRP and becomes harder to understand, test, and maintain.

Real-World Analogy

Imagine you own a house and hire a cleaner, a plumber, and an electrician. Each one has a specific responsibility:

• The cleaner cleans the house.
• The plumber fixes water leaks.
• The electrician repairs electric faults.

Now, imagine one person doing all three jobs. If anything goes wrong, it’s harder to pinpoint the issue or fix just one part without affecting the others.

The same concept applies in programming.

Code Example Without SRP (Bad Practice)

class Report {
public:
    void generateReport() {
        // Logic to generate the report
    }

    void printReport() {
        // Logic to print the report
    }

    void saveToFile() {
        // Logic to save the report to a file
    }
};

What’s wrong here?

This class is doing too much:

1. Creating a report
2. Printing the report
3. Saving the report

These are different responsibilities, and each one might change for a different reason.

Code Example With SRP (Good Practice)

class ReportContent {
public:
    void generateReport() {
        // Only generates the report content
    }
};

class ReportPrinter {
public:
    void printReport() {
        // Only responsible for printing
    }
};

class ReportSaver {
public:
    void saveToFile() {
        // Only responsible for saving
    }
};

Now, each class does only one job, and if anything changes, you only need to modify that specific class. This makes the code clean, testable, and easy to maintain.

Why is SRP Important?

• Improves readability – Each class has a clear and focused purpose.
• Simplifies testing – You can test each class independently.
• Reduces bugs – Changes in one class don’t affect others unexpectedly.
• Supports reusability – Classes with a single purpose are easier to reuse.
• Enhances maintainability – Easier to fix issues or update code later.

How to Identify SRP Violations

Ask yourself:

• Does the class do more than one thing?
• Can I split this into smaller, more focused classes?
• Are there multiple reasons this class might change?

If the answer is yes, then it’s time to refactor your code using SRP.

Best Practices to Follow

• Focus each class on one and only one responsibility.
• Write unit tests to check if a class is tightly focused.
• Organize files and folders based on responsibilities.
• Keep your methods short and clear.
• Refactor often when a class starts growing too large.

Conclusion

The Single Responsibility Principle is all about keeping your code clean, organized, and focused. By giving each class a single job, you make your codebase easier to understand, test, and maintain — especially as your project grows.

You can also Visit other tutorials of Embedded Prep 

• What is eMMC (Embedded MultiMediaCard) memory ?
• Top 30+ I2C Interview Questions
• Bit Manipulation Interview Questions
• Structure and Union in c
• Little Endian vs. Big Endian: A Complete Guide
• Merge sort algorithm

Special thanks to @mr-raj for contributing to this article on Embedded Prep

Definition (Simple Terms)

Dependency Inversion Principle : “High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.”

Let’s Break It Down

This sounds complex, right? Let’s simplify.

Imagine you’re building a robot. The brain of the robot is the high-level module — it decides what to do. The legs or arms are low-level modules — they do the actual work.

Now, if the robot’s brain is tightly connected (depends directly) to the specific type of leg motors, then anytime you change the leg motors, you also have to change the brain’s code. That’s bad.

DIP says: “Don’t connect the brain directly to the legs. Let both talk through a common language (interface or abstract class).”

That way, if you ever replace the legs with wheels, the brain doesn’t need to know — it just sends the same instructions.

Goal of DIP

• Reduce tight coupling between classes/modules.
• Increase flexibility, maintainability, and testability of code.
• Make it easier to swap or change parts of the system.

Traditional (Wrong) Design Without DIP

class Keyboard {
public:
    void input() {
        std::cout << "Keyboard input received\n";
    }
};

class Computer {
    Keyboard keyboard;  // Direct dependency
public:
    void getInput() {
        keyboard.input();
    }
};

What’s wrong?

• Computer is tightly bound to Keyboard.
• If you want to replace Keyboard with Touchscreen, you have to change the Computer class.

DIP Applied (Right Way)

Step 1: Create an abstraction (interface)

class IInputDevice {
public:
    virtual void input() = 0; // Pure virtual function
    virtual ~IInputDevice() = default;
};

Step 2: Implement the abstraction in concrete classes

class Keyboard : public IInputDevice {
public:
    void input() override {
        std::cout << "Keyboard input received\n";
    }
};

class Touchscreen : public IInputDevice {
public:
    void input() override {
        std::cout << "Touchscreen input received\n";
    }
};

Step 3: Depend on the abstraction

class Computer {
    IInputDevice* inputDevice; // Depends on abstraction
public:
    Computer(IInputDevice* device) : inputDevice(device) {}

    void getInput() {
        inputDevice->input();  // Calls via interface
    }
};

Step 4: Use it flexibly

int main() {
    Keyboard kb;
    Touchscreen ts;

    Computer comp1(&kb);  // Works with keyboard
    Computer comp2(&ts);  // Works with touchscreen

    comp1.getInput();  // Output: Keyboard input received
    comp2.getInput();  // Output: Touchscreen input received

    return 0;
}

Key Takeaways

Benefits of Using DIP

• Easy to switch or add new modules (like adding a mouse or joystick).
• Improved testability (you can inject mock devices for testing).
• Better code organization and readability.
• Promotes Open/Closed Principle (open to extension, closed to modification).

Real-World Analogy

Think of a power plug. Your phone charger (low-level device) and your home socket (high-level supply) both depend on a standard plug shape (interface). If tomorrow you buy a new charger, as long as it supports the same plug, you don’t need to rewire your home.

DIP and Unit Testing

Since you depend on interfaces, you can write mock versions during testing:

class MockInputDevice : public IInputDevice {
public:
    void input() override {
        std::cout << "Mock input for testing\n";
    }
};

Final Thoughts

• DIP doesn’t mean no dependencies. It means depend on abstractions rather than concrete implementations.
• It’s not about eliminating dependencies, but inverting the direction of dependency to favor abstraction.

Full Comparison of SOLID Principles

Detailed Descriptions Per Column

Core Idea

• S: One job per class.
• O: Add, don’t change.
• L: Substitutable behavior.
• I: Small, focused interfaces.
• D: Depend on interfaces, not concrete classes.

Real-World Analogy

• Each principle is inspired by common-sense organization and responsibility. These analogies help you remember and visualize them better.

Code Hint

• Gives a small direction of what to implement or avoid in code for each principle.

Benefits

• Each principle improves maintainability, testability, and flexibility in different ways. Together, they lead to a clean and scalable architecture.

Violations Lead To

• Points out what goes wrong when the principle is not followed — like tight coupling, difficult changes, or confusing code.

How They Work Together (Flow Summary)

1. SRP gives each class one purpose.
2. OCP lets you grow your app by adding features instead of modifying old code.
3. LSP ensures that your new classes don’t break the old ones.
4. ISP keeps your classes from knowing too much they don’t care about.
5. DIP connects your parts flexibly through abstraction.

You can also Visit other tutorials of Embedded Prep 

• What is eMMC (Embedded MultiMediaCard) memory ?
• Top 30+ I2C Interview Questions
• Bit Manipulation Interview Questions
• Structure and Union in c
• Little Endian vs. Big Endian: A Complete Guide
• Merge sort algorithm

Special thanks to @mr-raj for contributing to this article on Embedded Prep

The Interface Segregation Principle (ISP) is one of the five SOLID principles of object-oriented programming. It states:

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

In simpler terms, this principle encourages splitting large, unwieldy interfaces into smaller, more specific ones so that classes only need to implement the methods they actually use.

Why Interface Segregation Principle Matters

When designing systems—especially in embedded software and large-scale applications—overly fat interfaces can lead to:

• Unnecessary code coupling
• Wasted resources in constrained systems
• Fragile software that’s hard to maintain or extend

By adhering to ISP, you build cleaner, modular, and more maintainable codebases that are easier to test and evolve over time.

What does this mean (simple version)?

Imagine an interface (abstract class) with 10 methods.
You only need 2 of them — but you still have to override all 10, even the ones you don’t use. 😖

That’s bad design.

With ISP, you split that big interface into smaller purpose-specific ones so that:

• Classes only implement what they really need
• They’re not bloated with useless methods

Real-Life Analogy

Let’s say you go to a restaurant.

If you only want coffee ☕, but they hand you a menu with 100 items, and ask you to order from every category — that’s overwhelming, right?

Wouldn’t it be better if they had a “Drinks” menu separate from the “Meals” and “Desserts”?

That’s Interface Segregation — keep things small, focused, and relevant.

Bad Example: Violates ISP

Let’s create a fat interface:

class IMachine {
public:
    virtual void print() = 0;
    virtual void scan() = 0;
    virtual void fax() = 0;
};

Now you want to create a basic printer:

class OldPrinter : public IMachine {
public:
    void print() override {
        cout << "Printing..." << endl;
    }

    void scan() override {
        // Not supported
        throw runtime_error("Scan not supported");
    }

    void fax() override {
        // Not supported
        throw runtime_error("Fax not supported");
    }
};

Problem:

• You’re forced to implement scan() and fax() even if your class doesn’t need them.
• You end up writing empty methods or throwing exceptions — that’s bad.

Good Design: Follows ISP

Split the large interface into smaller ones:

class IPrinter {
public:
    virtual void print() = 0;
};

class IScanner {
public:
    virtual void scan() = 0;
};

class IFax {
public:
    virtual void fax() = 0;
};

Now your classes only implement what they actually need:

class BasicPrinter : public IPrinter {
public:
    void print() override {
        cout << "Basic printing..." << endl;
    }
};

class MultiFunctionPrinter : public IPrinter, public IScanner, public IFax {
public:
    void print() override {
        cout << "Printing..." << endl;
    }

    void scan() override {
        cout << "Scanning..." << endl;
    }

    void fax() override {
        cout << "Faxing..." << endl;
    }
};

Now:

• BasicPrinter isn’t forced to implement scan() or fax()
• Each class only depends on what it actually uses
• You’re following the Interface Segregation Principle

How to Spot ISP Violations

Tips to Apply ISP

• 🔹 If your interface has more than 3–4 methods, check if it can be split.
• 🔹 Group methods by behavior (e.g., Print, Scan, Fax = 3 separate concerns).
• 🔹 Don’t overdo it — small, cohesive interfaces are ideal.
• 🔹 Use multiple inheritance of interfaces for combining features in C++.

ISP Mini Project Idea

Let’s say you’re building a Vehicle system.

Bad:

class IVehicle {
public:
    virtual void fly() = 0;
    virtual void drive() = 0;
    virtual void sail() = 0;
};

Now what if you just want to implement a car? 🚗

Instead:

class IDriveable {
public:
    virtual void drive() = 0;
};

class IFlyable {
public:
    virtual void fly() = 0;
};

class ISailable {
public:
    virtual void sail() = 0;
};

Now a car only implements IDriveable, and a boat only implements ISailable.
No more useless methods!

Summary of ISP

Common Ground Between SRP and ISP

Key Difference Between SRP and ISP

In Summary:

➕ SRP:

“Don’t overload classes with multiple jobs.”

➕ ISP:

“Don’t overload interfaces with methods clients won’t use.”

Think of it like:

Side-by-Side Quick Example

// SRP
class ReportGenerator {
public:
    void generate() { /* ... */ }
};
// Bad: also sends emails or logs things

// ISP
class IPrinter {
public:
    virtual void print() = 0;
};

class IScanner {
public:
    virtual void scan() = 0;
};
// Good: only implement what you need

Final Takeaway:

🔧 SRP keeps classes focused.
🔌 ISP keeps interfaces focused.

They work hand-in-hand to make your code clean, modular, and friendly to change.

You can also Visit other tutorials of Embedded Prep 

• What is eMMC (Embedded MultiMediaCard) memory ?
• Top 30+ I2C Interview Questions
• Bit Manipulation Interview Questions
• Structure and Union in c
• Little Endian vs. Big Endian: A Complete Guide
• Merge sort algorithm

Special thanks to @mr-raj for contributing to this article on Embedded Prep

Introduction of Adapter Design Pattern

Adapter Design Pattern : When working on large software systems, you may come across situations where two incompatible interfaces need to work together. Instead of modifying existing code (which may be risky or impossible), you can use the Adapter Pattern to make them compatible.

The Adapter Pattern acts like a bridge between two interfaces. It’s part of the Structural Design Patterns family in C++.

What is the Adapter Design Pattern?

The Adapter Design Pattern allows incompatible interfaces to work together by wrapping an existing class with a new interface.

In simple terms, it’s like using a power plug adapter that lets a U.S. plug fit into a European socket.

Real-life Analogy

Imagine you have an old VGA cable that only works with projectors, but your laptop only has an HDMI port. You can’t plug it in directly. So, you use an HDMI-to-VGA adapter. Now your laptop can talk to the projector!

That’s exactly what the Adapter Pattern does in code.

Components of the Adapter Pattern

1. Target – The expected interface (what your code is designed to use)
2. Adaptee – The existing class that needs adapting
3. Adapter – The class that wraps the Adaptee and makes it compatible with Target

When to Use the Adapter Pattern

• When you want to reuse an existing class, but its interface doesn’t match what you need.
• When you want to decouple code from third-party libraries or legacy code.
• When integrating new features into old systems.

Adapter Pattern in C++ – Code Example

Let’s look at a simple C++ example to understand how it works.

Problem:

We have an existing OldPrinter class. But our system expects printers to use the NewPrinterInterface.

Step 1: Define the Target Interface

// Target Interface
class NewPrinterInterface {
public:
    virtual void printDocument(const std::string& text) = 0;
    virtual ~NewPrinterInterface() {}
};

Step 2: Existing Class (Adaptee)

// Adaptee
class OldPrinter {
public:
    void oldPrint(const std::string& text) {
        std::cout << "Old Printer Output: " << text << std::endl;
    }
};

Step 3: Create the Adapter

// Adapter
class PrinterAdapter : public NewPrinterInterface {
private:
    OldPrinter* oldPrinter;

public:
    PrinterAdapter(OldPrinter* printer) : oldPrinter(printer) {}

    void printDocument(const std::string& text) override {
        // Convert the request to match the old interface
        oldPrinter->oldPrint(text);
    }
};

Step 4: Client Code

int main() {
    OldPrinter* legacyPrinter = new OldPrinter();

    // Use adapter to make it compatible with the new interface
    NewPrinterInterface* printer = new PrinterAdapter(legacyPrinter);

    printer->printDocument("Hello, Adapter Pattern!");

    delete printer;
    delete legacyPrinter;

    return 0;
}

Output

Old Printer Output: Hello, Adapter Pattern!

Success! The OldPrinter works with the new system using the adapter.

Types of Adapters

• Class Adapter (using inheritance): Inherit from both Target and Adaptee (only works in languages with multiple inheritance like C++).
• Object Adapter (using composition): Use a reference to Adaptee inside the Adapter. This is more flexible and used in our example above.

Benefits of Adapter Pattern

• Promotes reusability of existing classes
• Helps in code migration and integration
• Makes your design more flexible and maintainable

Drawbacks

• Adds extra layers of code
• May lead to performance overhead
• Can make debugging slightly harder due to indirection

Adapter vs. Other Patterns

Conclusion

The Adapter Pattern is a powerful tool in a C++ developer’s design toolbox. It allows your code to stay clean, extensible, and compatible with legacy or third-party systems. By wrapping old interfaces with new ones, you avoid rewriting or duplicating code.

Use it wisely when integrating different systems — and you’ll be building robust and scalable software like a pro!

FAQs – Adapter Pattern in C++

Q1. Is Adapter Pattern a structural design pattern?
Yes, it’s part of the Structural design patterns.

Q2. Can we implement Adapter without inheritance?
Yes! You can use composition (object adapter) for a more flexible solution.

Q3. Is Adapter Pattern the same as a Wrapper?
They are similar. A wrapper is a broader term; an adapter is a type of wrapper that converts interfaces.

You can also Visit other tutorials of Embedded Prep 

• What is eMMC (Embedded MultiMediaCard) memory ?
• Top 30+ I2C Interview Questions
• Bit Manipulation Interview Questions
• Structure and Union in c
• Little Endian vs. Big Endian: A Complete Guide
• Merge sort algorithm

Special thanks to @mr-raj for contributing to this article on Embedded Prep