This document outlines the SOLID principles of object-oriented design, including Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. It defines each principle, provides examples, and discusses the benefits, such as increasing reusability, making code more extensible and flexible, and reducing coupling between modules. Applying these principles helps create software that is well-designed and able to easily handle changes, improving developer and customer satisfaction.

1. OO Design: S.O.L.I.D principles
Technical team
DNB 2015
Page 1Confidential
Presenters: Quang Nguyen, Lan Nguyen

2. Page 2Confidential
Outline
SOLID principles introduction
Purpose of use.
Definition, explanation, examples and benefits of
+ Single responsibility principle (SRP)
+ Open – close Principle (OCP)
+ Linkov's substitution principle (LSP)
+ Interface segregation principle (ISP)
+ Dependency inversion principle (DIP)
Conclusion
Q&A

3. Page 3Confidential
Design Matter: Doing Better with Less

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.

10. Single Responsibility principle (SRP)
Page 10Confidential

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.

13. SRP - Example
Page 13Confidential

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.

19. OCP - Example
Page 19Confidential

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.

21. - Template Method Design Pattern
- Strategy Design Pattern.
Reference

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

24. LSP - Example
Page 24Confidential

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.

26. Interface segregation Principle (ISP)
Page 26Confidential

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.

29. ISP - Example
Page 29Confidential

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.

31. Dependence Inversion Principle (DIP)
Page 31Confidential

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

34. DIP - Example
Page 34Confidential

35. Demo - Explanation
Page 35Confidential

36. DIP - Explanation
Page 36Confidential
- Abstractions should not depend upon details
- Details should depend on abstractions

37. Page 37Confidential
- Spring frameworks' component
- Using Dependency Injection pattern
- Automatic class instantiation (from external files or
annotation)
- Entirely remove the low-level component dependencies
and achieve true DIP.
IoC Container & Dependency Injection

38. DIP – Benefit
Page 38Confidential
- Reusable
- Flexible
- More readable.
- Higher cohesion - lower coupling
- Remove dependencies between low and high level
modules.
- Violate DIP => Violate OCP or LSP.
- More classes != More complicated

39. Should we always apply DIP anywhere?
Question

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

42. Q&A
Page 42Confidential

43. References
Page 43Confidential
http://www.oodesign.com/
http://www.codeproject.com/Articles/703634/SOLID-
architecture-principles-using-simple-Csharp
https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-
object-oriented-design
Object oriented analysis and design book by Head First
Design pattern
Dependency Injection and IoC container in Spring Framework