Scribd
Upload
2 views7 pages

Solid Properties

The document provides a comprehensive guide to the SOLID principles, which are essential object-oriented design principles aimed at creating maintainable and scalable software. Each principle is defined with real-life analogies and examples of both good and bad implementations. The principles include Single Responsibility, Open/Closed, Liskov Substitution, and Interface Segregation, each emphasizing the importance of clear responsibilities and extensibility in software design.

Uploaded by

2022ugec037
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
2 views7 pages

Solid Properties

The document provides a comprehensive guide to the SOLID principles, which are essential object-oriented design principles aimed at creating maintainable and scalable software. Each principle is defined with real-life analogies and examples of both good and bad implementations. The principles include Single Responsibility, Open/Closed, Liskov Substitution, and Interface Segregation, each emphasizing the importance of clear responsibilities and extensibility in software design.

Uploaded by

2022ugec037
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

Understanding SOLID Principles with

Colorful Examples
A Comprehensive Guide
February 9, 2025

Introduction
Software design principles help developers create maintainable, scalable, and
robust software. The SOLID principles are five key object-oriented design
principles that ensure software is easy to manage and extend.

What is SOLID?
SOLID is an acronym for:

• Single Responsibility Principle (SRP)

• Open/Closed Principle (OCP)

• Liskov Substitution Principle (LSP)

• Interface Segregation Principle (ISP)

• Dependency Inversion Principle (DIP)

1
1 Single Responsibility Principle (SRP)
1.1 Definition
A class should have only one reason to change, meaning it should have only
one job.

1.2 Real-Life Analogy


Imagine a restaurant. The chef cooks food, and the waiter serves customers.
If the chef also starts serving food, it violates SRP because now the chef has
two responsibilities.

1.3 Example (Bad)


class Report {
public :
void generateReport () { /* Generates report */ }
void printReport () { /* Prints report */ }
};

Listing 1: Bad Example of SRP


Why is this bad? The class has two responsibilities: generating and
printing the report. If printing logic changes, the class will have to be mod-
ified, violating SRP.

1.4 Example (Good)


class ReportGenerator {
public :
void generateReport () { /* Generates report */ }
};

class ReportPrinter {
public :
void printReport () { /* Prints report */ }
};

Listing 2: Good Example of SRP


Why is this good? Each class now has a single responsibility. If printing
logic changes, only the ReportPrinter class needs modification.

2
2 Open/Closed Principle (OCP)
2.1 Definition
Software entities should be open for extension but closed for modification.

2.2 Real-Life Analogy


Imagine a smartphone. You can install new apps (extend functionality) with-
out modifying the phone’s internal software.

2.3 Example (Bad)


class Invoice {
public :
void processInvoice ( string type ) {
if ( type == " paper " ) { /* Paper invoice */ }
else if ( type == " digital " ) { /* Digital invoice */ }
}
};

Listing 3: Bad Example of OCP


Why is this bad? If a new invoice type is added, the class must be
modified, violating OCP.

2.4 Example (Good)


class Invoice {
public :
virtual void process () = 0;
};

class PaperInvoice : public Invoice {


public :
void process () override { /* Paper invoice */ }
};

class DigitalInvoice : public Invoice {


public :
void process () override { /* Digital invoice */ }
};

Listing 4: Good Example of OCP

3
Why is this good? New invoice types can be added without modifying
existing code.

4
3 Liskov Substitution Principle (LSP)
3.1 Definition
A subclass should be replaceable by its base class without altering the cor-
rectness of the program.

3.2 Real-Life Analogy


Imagine your parent says: ”You can borrow my car anytime!” LSP says: You
should be able to use ANY car (sports car, truck, SUV) without changing
how you drive.

3.3 Example (Bad)


class Bird {
public :
virtual void fly () { /* Birds fly */ }
};

class Penguin : public Bird {


public :
void fly () override {
throw " I can ’t fly ! " ;
}
};

Listing 5: Bad Example of LSP


Why is this bad? A penguin is a bird but cannot fly, breaking the
expectation set by the base class.

3.4 Example (Good)


class Bird {
public :
virtual void move () { /* Birds move */ }
};

class FlyingBird : public Bird {


public :
void move () override { /* Flying behavior */ }
};

class Penguin : public Bird {

5
public :
void move () override { /* Waddle on ground */ }
};

Listing 6: Good Example of LSP


Why is this good? The base class is now defined in a way that accom-
modates all birds without forcing flight.

6
4 Interface Segregation Principle (ISP)
4.1 Definition
Clients should not be forced to depend on interfaces they do not use.

4.2 Real-Life Analogy


Imagine a restaurant menu. A vegetarian customer should not be forced to
look at a menu with only meat dishes. Instead, a specialized vegetarian menu
makes more sense.

4.3 Example (Bad)


class Worker {
public :
virtual void work () = 0;
virtual void eat () = 0;
};

class Robot : public Worker {


public :
void work () override { /* Robots work */ }
void eat () override { throw " I don ’t eat ! " ; }
};

Listing 7: Bad Example of ISP


Why is this bad? Robots do not need to eat, but they are forced to
implement eat().

You might also like