Understanding SOLID Principles in OOP programming

S O L I D
P R I N C I P L E S
A F O U N D A T I O N F O R O B J E C T -
O R I E N T E D D E S I G N

Single Responsibility Principle (SRP)
a.
Open/Closed Principle (OCP)
b.
Liskov Substitution Principle (LSP)
c.
Interface Segregation Principle (ISP)
d.
Dependency Inversion Principle (DIP)
e.
I N T R O D U C T I O N
T O S O L I D
SOLID principles are a set of five design principles that guide
developers to create more maintainable and scalable software
systems.
SOLID principles provide a foundation for creating robust, flexible,
and easily maintainable software. They address common challenges
in software design and help developers create systems that are
resilient to changes, easy to extend, and simple to understand.

S I N G L E R E S P O N S I B I L I T Y
P R I N C I P L E ( S R P )
Definition:
SRP states that a class should have only one reason to
change. In other words, a class should have only one
responsibility or job within the software system.
Importance:
By adhering to SRP, code becomes more maintainable
and less prone to bugs. Each class or module becomes
focused on a specific task, making it easier to
understand and modify without affecting other
unrelated parts of the system.
Testing – A class with one responsibility will have far fewer test cases.
1.
Lower coupling – Less functionality in a single class will have fewer dependencies.
2.
Organization – Smaller, well-organized classes are easier to search than monolithic ones.
3.
// Report class responsible for generating reports
class Report {
public void generateReport(String data) {
// ... code for generating report
}
}
// Logger class responsible for logging data
class Logger {
public void logData(String data) {
// ... code for logging data
}
}

O P E N / C L O S E D P R I N C I P L E
( O C P )
Definition:
The Open/Closed Principle (OCP) states that software
entities (classes, modules, functions) should be open for
extension but closed for modification. This means that
the behavior of a module can be extended without
altering its source code.
Importance:
OCP promotes code stability and scalability. It allows
developers to add new features or functionality by
creating new classes or modules without changing
existing code. This reduces the risk of introducing bugs
in already tested and working code.
Use of interfaces or abstract classes to define the base functionality, making it easier to adhere
to the OCP.
// Base class
class Shape {
public double area() {
return 0.0; // default implementation
}
}
// Derived class extending Shape
class Rectangle extends Shape {
// ... code for calculating rectangle area
}
}
// Derived class extending Shape
class Circle extends Shape {
// ... code for calculating circle area
}
}

L I S K O V S U B S T I T U T I O N
P R I N C I P L E ( L S P )
Definition:
The Liskov Substitution Principle (LSP) states that
objects of a superclass should be substitutable with
objects of a subclass without affecting the correctness
of the program. In simpler terms, a derived class should
be able to replace its base class without altering the
desirable properties of the program.
Importance:
LSP ensures that the inheritance hierarchy is well-
designed and that derived classes don't introduce
unexpected behavior. Adhering to LSP enhances code
reliability and maintainability.
// Base class
class Bird {
public void fly() {
// ... code for flying
}
}
// Derived class extending Bird
class Sparrow extends Bird {
// Additional code specific to Sparrow
}

I N T E R F A C E S E G R E G A T I O N
P R I N C I P L E ( I S P )
Definition:
The Interface Segregation Principle (ISP) suggests that a
client should not be forced to depend on interfaces it
does not use. In other words, it's better to have multiple
small, specific interfaces rather than a large, general-
purpose one.
Importance:
ISP enhances code flexibility and maintainability by
preventing clients from being burdened with
unnecessary methods. It encourages a more modular
and cohesive design.
// Interface for work-related functionality
interface Workable {
void work();
}
// Interface for managerial functionality
interface Managable {
void manage();
}
// Class implementing both interfaces
class Manager implements Workable, Managable {
public void work() {
// ... code for working
}
public void manage() {
// ... code for managing tasks
}
}
Encourage the creation of small, cohesive interfaces tailored to specific client needs.

D E P E N D E N C Y I N V E R S I O N
P R I N C I P L E ( D I P )
Definition:
The Dependency Inversion Principle (DIP) suggests that
high-level modules should not depend on low-level
modules. Instead, both should depend on abstractions.
It also introduces the idea that abstractions should not
depend on details; details should depend on
abstractions.
Importance:
DIP promotes decoupling between high-level and low-
level modules, making the system more flexible and
easier to maintain. It encourages the use of abstractions,
allowing for changes in implementation details without
affecting higher-level modules.
// Abstraction for a light bulb
interface LightBulb {
void turnOn();
}
// Class implementing LightBulb abstraction
class StandardBulb implements LightBulb {
public void turnOn() {
// ... code for turning on the bulb
}
}
// Class depending on LightBulb abstraction
class Switch {
private LightBulb bulb;
public Switch(LightBulb bulb) {
this.bulb = bulb;
}
public void operate() {
bulb.turnOn();
}
}
The importance of relying on abstractions to minimize dependencies between modules.

Recap of SOLID Principles:
Single Responsibility Principle (SRP): Each class should have only one reason to change.
Open/Closed Principle (OCP): Software entities should be open for extension but closed for
modification.
Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types
without altering program correctness.
Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces
they do not use.
Dependency Inversion Principle (DIP): High-level modules should not depend on low-level
modules; both should depend on abstractions.

Understanding SOLID Principles in OOP programming

More Related Content

Similar to Understanding SOLID Principles in OOP programming (20)

Recently uploaded (20)

Understanding SOLID Principles in OOP programming