Solid Principles

The SOLID principles  design principles in OO

programming intended to make software
designs more understandable, flexible, and
maintainable.
1. Single Responsibility Principle (SRP)
2. Open/Closed Principle (OCP)
3. Liskov Substitution Principle (LSP)
4. Interface Segregation Principle (ISP)
5. Dependency Inversion Principle (DIP)
 2. Open/Closed Principle (OCP)
Robert C. Martin
“the most important principle of object-oriented
design”
Bertrand Meyer – 1988
“Object-Oriented Software Construction”
“Software entities (classes, modules, functions,
etc.) should be open for extension, but closed
for modification.”
 2. Open/Closed Principle (OCP)
Why Should You Use the Open-Closed Principle?
• You don’t need to re-invent the wheel
• You focus on what is necessary
• You can avoid bugs
• Your code is more maintainable, testable, and
flexible
following the OCP will make your codebase loosely
coupled. With this the code is more flexible and
maintainable. And if you want, you can unit test
each class successfully.
 2. Open/Closed Principle (OCP)
How to Implement the Open-Closed Principle?
• Inheritance is only one way to implement the
Open Closed Principle.
• Because inheritance is only an Object Oriented
Design (OOD) basic pillar that allows the
extension of the functionality of an existing
class.
• To implement the Open Closed Principle one
can use an interface, an abstract class, abstract
methods, and virtual methods then inherit
them when you wants to extend functionality.
2. Open/Closed Principle (OCP)
3. Liskov Substitution Principle (LSP)
• The Liskov Substitution Principle is a
Substitutability principle in object-oriented
programming Language.
• This principle states that if S is a subtype of T, then
objects of type T should be replaced with objects
of type S.
• The LSP states that objects of a superclass should
be able to be replaced with objects of a subclass
without affecting the correctness of the program.
• In other words, a subclass should be able to extend
or replace the functionality of its parent class
without causing any issues in the code that uses it.
3. Liskov Substitution Principle (LSP)
• The LSP is closely related to the concept of
polymorphism, which allows objects of different
classes to be treated as objects of a common
superclass or interface.
• In the following example, first, we create the
Apple class with the method GetColor.
• Then, we create the Orange class, which inherits
the Apple class and overrides the GetColor
method of the Apple class.
• The point is that an Orange cannot be replaced by
an Apple, which results in printing the color of the
apple as Orange, as shown in the example below.
3. Liskov Substitution Principle (LSP)
3. Liskov Substitution Principle (LSP)
• Apple is the base class, and Orange is the child class,
i.e., there is a Parent-Child relationship.
• we can store the child class object in the Parent class
Reference variable, i.e., Apple apple = new Orange();
• and when we call the GetColor, i.e., apple.GetColor(),
then we are getting the color Orange, not the color of
an Apple.
• That means the behavior changes once the child
object is replaced, i.e., Apple stores the Orange object.
• This is against the LSP Principle.
• The Liskov Substitution Principle states that even if the
child object is replaced with the parent, the behavior
should not be changed.
3. Liskov Substitution Principle (LSP)
• Let’s modify the previous example to follow the LS
Principle.
• First, we need a generic base Interface, i.e., IFruit,
which will be the base class for both Apple and
Orange.
• Now, the IFruit variable can be replaced with its
subtypes, either Apple or Orange, and it will
behave correctly.
• In the code below, we created the super IFruit as
an interface with the GetColor method. Then, the
Apple and Orange classes were inherited from the
Fruit class and implemented the GetColor method.
3. Liskov Substitution Principle (LSP)
3. Liskov Substitution Principle (LSP)
• Now, run the application, and it should give
the output as expected, as shown in the below
image.

• Here, we follow the LSP as we can change the

object with its subtype without affecting the
behavior.