4. Introduction
Page 4Confidential
S.O.L.I.D is an acronym for the first five object-oriented
design(OOD) principles by Robert C. Martin, popularly
known as Uncle Bob.
S – Single Responsibility principle
O – Open-closed principle
L – Liskov’s substitution principle
I – Interface segregation principle
D – Dependency Inversion principle
5. What are the issues that developers
always face to in software development
lifecycle?
Question
6. Requirements change
Page 6Confidential
Your requirements will always change (and grow) over
time
Your system need to evolve to handle the changes.
We should build a software which is smartly designed
enough to change.
.
7. What is “Smartly-designed Software” ?
Page 7Confidential
Handle the changes with minimal re-factor and effort.
Extendable
Reusable
Flexible
8. Customer and Developer satisfaction
Page 8Confidential
Customers are satisfied because the software:
+ Work well
+ Keeps working - always.
+ Can be changed, upgraded easily
+ Reuse to build other software.
+ Extendable, Flexible.
Help the developers:
+ Handle the changes easily.
+ Code better in any programming languages.
9. Page 9Confidential
PURPOSE OF USE
When combined together, these principles will help your
software:
Become well and smartly-designed
Easily handle the changes
Make both customer and developer satisfied with their
work.
⇒Save money and time.
11. SRP - Definition
Page 11Confidential
“An object should have one and only one reason to
change”
12. SRP - Explanation
Page 12Confidential
Responsibility is a family of functions that serves
one particular purpose.
If you have a class having more than one reason to
change
=> you should split the class into multiple classes
base on their responsibilities.
14. SRP – Why splitting is important ?
Page 14Confidential
- If classes have more than one responsibility ?
- Each responsibility is an axis of change.
+ Codes become complicated
+ One change effects another
- Big classes:
+ Difficult to change
+ Harder to read
+ Bugs
15. SRP – Benefit
Page 15Confidential
Increase the reusability of source code
Make your classes smaller, lesser complicated.
Restrict effects to other modules when we change
source codes.
Easier to read and write => less to write bugs.
Higher cohesion, lower coupling.
Smaller classes and smaller methods will give you
more flexibility
More classes != more complicated
16. Open – Close Principle (OCP)
Page 16Confidential
17. OCP - Definition
Page 17Confidential
“An object should be opened for extension and
closed for modification”
18. OCP - Explanation
Page 18Confidential
- You should extend a class without modifying it.
- if you read and understand all source code to find
what they are supposed to do and update.
⇒ so hard
⇒ cost time, effort
⇒ bugs
- But it’s easy to extend the source code to meet
the new requirements.
20. OCP – Benefit
Page 20Confidential
- Restrict effects to others because when you
change code.
- Not need to read all old source codes that already
worked well.
- Extend the existing libraries.
22. Liskov's Substitution (LSP) - Definition
Page 22Confidential
“Objects should be replaceable with their base
classes without altering the correctness of the
program”
23. LSP - Explanation
Page 23Confidential
+ Should always use a base class or interface
instead of the subclasses.
+ This works correctly with any subclasses of X.
⇒ Extends without replacing any base class's
functions
25. LSP – Benefit
Page 25Confidential
- This is an extension of OCP
⇒Wrong LSP => wrong OCP
⇒ Inherit all OCP's benefits.
- Preventing bugs caused by subclasses.
27. ISP - Definition
Page 27Confidential
“A client should not implement an interface, if it
doesn't use that”
28. ISP - Explanation
Page 28Confidential
Clients should not be forced to implement interfaces
they don't use
=> Split a fat interface which has many methods
into many small interfaces.
30. ISP – Benefit
Page 30Confidential
- Smaller interface => more reusable
- Extendable
- Flexible
- Allows people to use only the parts of objects that
they need.
- High cohesion, low coupling
- Comply SRP.
32. DIP - Definition
Page 32Confidential
“High level model should not depend on low level
module, both should depend on abstractions
Abstractions should not depend on details.
Details should depend on abstractions”
33. DIP - Explanation
Page 33Confidential
- Low level module: implement basic and primary
operations
- High level module: encapsulate complex logic
- The high level classes should not directly use and
heavily depend on low level classes.
=> we should create abstraction layer between high
level classes and low level classes
40. Conclusion
Page 40Confidential
With S.O.L.I.D principles, our software:
Easily handle the changes
Become well and smartly-designed
Make both customer and developer satisfied with their
work.
⇒Save money and time.
41. OOP vs OOD
Page 41Confidential
Object oriented design (OOD) = OOP + Design principles.
⇒The source code applied OOD will be:
+ Object oriented
+ Re-usable
+ Flexible: can be changed with minimal efforts.
+ Extendable: can be extended without changing existing
codes