SOLID is a mnemonic device for 5 design principles of object-oriented programs (OOP) that result in readable, adaptable, and scalable code. S - Single Responsibility Principle. O - Open Closed Principle. L - Liskov Substitution Principle. I - Interface Segregation Principle. D - Dependency Inversion Principle.

1. S.O.L.I.D. Principles of Object-Oriented
Programming(OOP)
Prepared by – Kumaresh Chandra Baruri
Software Engineer

2. What is S.O.L.I.D?
The 5 principles of SOLID are -
1. Single-responsibility principle.
2. Open-closed principle.
3. Liskov substitution principle.
4. Interface segregation principle.
5. Dependency inversion principle.
SOLID is a mnemonic device for 5 design principles of object-oriented
programs (OOP) that result in readable, adaptable, and scalable code.

3. Single Responsibility Principle
Example: Software development team consists of -
1. Front-end designers do design,
2. The tester does testing and
3. Backend developer takes care of backend development.
Here everyone has a single job or responsibility.
“A class should have only one reason to change” i.e. every class should have
a single responsibility or single job or single purpose.

4. Single Responsibility Principle
Motivations-
• Maintainability.
• Testability.
• Flexibility and Extensibility.
• Parallel Development.
• Loose Coupling.
How?
• Single File - Single Class.
• The class/function itself should only perform one task.

5. Single Responsibility Principle
Problematic Codes:
RegisterService violates SRP
as it does –
1. Register a user,
2. Connect to the database, and
3. Send an email.

6. Single Responsibility Principle
Solution Codes:
It needs to split the class into three specific
classes that each accomplish a single job –
1. RegisterService
2. UserRepository and
3. EmailService

7. Open Closed Principle
Example: Derive new class from existing class -
1. Developer A needs to release an update for a library or framework.
2. Developer B wants some modification or add some feature on that.
3. Then developer B is allowed to extend the existing class created by
developer A which is extension.
4. Developer B is not supposed to modify the class directly. This refers
to closed for modification.
“software entities (classes, modules, functions, etc.) should be open for
extension, but closed for modification” which means you should be able to
extend a class behavior, without modifying it.

8. Open Closed Principle
Motivations-
• Maintain stability of the existing codes.
• Reduce the cost of a business change requirement.
• Reduce testing of existing code.
• Write new functionality without altering existing codes.
• Loose coupling.
How?
• By Inheritance, Polymorphism and Abstraction, OCP can
be accomplished.

9. Open Closed Principle
Problematic Codes:
AreaCalculator does not follow OCP as
1. It handles only rectangle and circle.
2. No way to calculate for square or others.

10. Open Closed Principle
Solution Codes: Using abstraction -
Using an abstract class – Shape, any area can
be managed.

11. Liskov Substitution Principle
Motivations-
• If S is a subtype of T, then objects of type T should be replaced with
the objects of type S.
• No type casting is required so that codebase maintainability is
easier.
• Without LSP, every time we add or modify a subclass and
consequently to change multiple places. This is difficult and error-
prone.
“Derived or child classes must be substitutable for their base or parent
classes” which means any class that is the child of a parent class should
be usable in place of its parent without any unexpected behavior.

12. Liskov Substitution Principle
How?
• It needs to create generic base class.
• With Inheritance, Polymorphism and Abstraction, LSP can be
accomplished.

13. Liskov Substitution Principle
Problematic Codes
Orange class is breaking base class
behavior -
1. The output is - apple color is orange.
2. Child class changed the behavior of base class which is
opposite of LSP.

14. Liskov Substitution Principle
Solution Codes
Based on generic base class Fruit
1. Both orange and apple implement it.
2. Parent class’s behavior is not changed.

15. Interface Segregation Principle
Motivations-
• First, no class should be forced to implement any method(s) of an interface
they don’t use.
• Secondly, instead of creating large or one can say fat interfaces, create
multiple smaller interfaces with the aim that the clients should only think about
the methods that are of interest to them.
• There is less code carried between classes. Less code means fewer bugs.
“Do not force any client to implement an interface which is irrelevant to them” which
means – “Many client-specific interfaces are better than one general-purpose
interface.”

16. Interface Segregation Principle
How?
• Any unused part of the method should be removed or split into a
separate method into the interfaces. Client implements interface as per
their demand.
Problematic Codes which violates ISP

17. Interface Segregation Principle
Problematic Codes which violates ISP
This code violates ISP in the following ways –
1. Both the classes implemented same interface
IWorker abd inherited unnecessary methods.
2. FullTimeEmployee class does not need the
CalculateWorkedSalary() function.
3. ContractEmployeeclass does not need the
CalculateNetSalary().

18. Interface Segregation Principle
Solution:
In order to solve the problems above –
1. It needs to split the general interface IWorker into one base interface,
IBaseWorker, and two child interfaces IFullTimeWorkerSalary and
IContractWorkerSalary.
2. The general interface - IBaseWorker contains methods that all workers
share.
3. The child interfaces split up methods by worker type, FullTime with a
salary or Contract that gets paid hourly.

19. Interface Segregation Principle
Solution Codes

20. Interface Segregation Principle
Solution Codes
The end classes now only contain methods and properties that further their goal and thus achieve the ISP principle.

21. Dependency Inversion Principle
Motivations-
• High-level modules should not depend on low-level modules. Instead,
both should depend on abstractions (interfaces)
• Abstractions should not depend on details. Details (like concrete
implementations) should depend on abstractions.
• If dependencies are minimized, changes will be more localized and
require less work to find all affected components.
The rule states that -
One should depend upon abstractions, but not concretions.

22. Dependency Inversion Principle
How?
• Create an abstraction layer for the lower-level classes.
• DIP decouples high and low-level components and instead connects both
to abstractions.
Problematic Codes which violates DIP

23. Dependency Inversion Principle
Problems:
• When the store asks us to enable customers to add DVDs to their
shelves.
• In order to fulfil the demand, it needs to –
1. Create a new DVD class.
2. Modify the Shelf class so that it can accept DVDs.
3. This also breaks OCP.

24. Dependency Inversion Principle
Solution:
The solution is to create an abstraction layer for the lower-level classes
(Book and DVD).

25. Dependency Inversion Principle
Solution:
1. DVD/Book implements Product interface(abstraction).
2. Shelf can reference the Product interface instead of its
implementations (Book and DVD)
The refactored code also allows us to introduce new product types (for instance, Magazine) later on.