SOLID is a set of 5 design principles of Object Oriented Design in software engineering intended to make software development more- Flexible Easier to maintain Easier to understand.

1. 1
SOLID Design Principles
Md Shohag Mia
eshohag@outlook.com

2. 2
SOLID- What does mean it?
SOLID is a set of 5 design principles of Object Oriented Design in software engineering intended to make
software development more-
Flexible
Easier to maintain
Easier to understand

3. 3
What is SOLID?
The SOLID principles of Object Oriented Design include these five principles:
S – Single Responsibility (SRP)
O – Open/Closed Principle (OCP)
L – Liskov Substitution Principle (LSP)
I – Interface Segregation Principle (ISP)
D – Dependency Inversion (DIP)

4. 4
Why we should care?
 Cleaner code
 Code smells are kept away
 Codebase that is maintainable, expandable & understandable
 Usually integrated in Agile methodologies, i.e. Scrum
 Loose coupling (DIP)

5. 55
Single Responsible Principle
5
A class should have only a single responsibility to
carry & one reason to changes.

6. 6
Is it supported for single responsible principle?

7. 7
Code Sample

8. 88
Open/Closed Principle
8
Software entities (classes, modules, functions, etc.)
should be open for extension, but closed for
modification.

9. 9
Code sample
Added a new feature

10. 10
Code sample

11. 1111
Liskov Substitution Principle
11
Functions that use pointers or references to base
classes must be able to use objects of derived classes
without knowing it.
Example:
If Child is a Subtype of Parent then objects of type Parent
may be replaced with objects of type Child

12. 12
Code sample

13. 13
Code sample

14. 1414
Interface Segregation Principle
14
Clients should not be forced to depend upon interfaces that
they do not use.
Example:
Our client are totally independent because if they are not able to
take features. If needed in future than they can.

15. 15
Code sample

16. 1616
Dependency Inversion Principle
16
High-level modules should not depend on low-level
modules. Both should depend on abstractions (e.g.
interfaces).
Abstractions should not depend on details. Details
(concrete implementations) should depend on abstractions.
N.B: Implementation Business Logic Layer/Data Access Layer

17. 17
Code sample

18. 1818
Follow Me
GitHub- https://github.com/eshohag/SOLID
SlideShare- https://www.slideshare.net/MDShohagMia
Linkedin- https://www.linkedin.com/in/eshohag/
Twitter- https://twitter.com/shohagds
18

19. 19
Q & A

20. 20
THANK YOU