This document discusses the SOLID principles of object-oriented programming and agile design. It defines each principle: single responsibility, open/closed, Liskov substitution, interface segregation, and dependency inversion. For each principle, it provides an example of how to apply the principle to code through refactoring existing code. It also discusses object-oriented concepts like polymorphism that relate to the SOLID principles.

1. S.O.L.I.D – Principles of
Object Oriented
Programming and Agile
Design
Name: Adedapo Adedamola
Twitter: @ichDamola

2. Content
◉ Bad code - Symptoms
◉ OOP - Polymorphism
◉ S.O.L.I.D principles
 Single Responsibility
 The Open/Close
 The Liskov Substitution
 The Interface Segregation
 The Dependency Inversion
◉ End 2

3. Bad Code
3
Good code explains what it is doing(Oh, yes!). Bad code
doesn’t (Umm... wait, what was I thinking then?)
 A bad code is code a programmer writes, who doesn’t
think much about future changes and ignores the
possibility of other developers touching it.

4. 4
Are you angry?...

5. Symptoms of bad code
5
1. Rigidity
 Code that have dependencies that spread out in so
many defferent directions, that you cannot make an
isolated change to without changing everything else
around it.
 Code dependencies in undesirable ways

6. Symptoms of bad code
6
2 . Fragility
 Is the tendency of the code to break in many places
even when you change it in one place. But they break
in part or parts of the code that has no relationship with
what you changed. - Fragile code breaks in bizarre
ways that you cannot predict.
 Data structures dependencies in undesirable ways

7. Symptoms
of bad code
7
Highest level program
e.g utility.py
Lowest level program
6 2
4 12 3 1
- * /
1
methods
- * / - * / - * /

8. 4. I- Interface
Segregation
8
 Client should not be forced to depend on
methods they do not use.

9. 3. I- Interface
Segregation
9
Highest level program
e.g utility.py
6 2
4 12 3 1
- * / -
1
methods
Lowest level program

10. 10
By: Ugonna Thelma

11. Object Oriented
Programming
11
OOP
 This is about managing dependencies by selectively
reinventing certain key dependencies in your
architecture so that you can prevent, code rigidity,
fragility and non-reusability.

12. Object Oriented
Programming
12
Polymorphism
 Gives you the ability to create one module calling
another and yet have the compile time dependency
point against the flow of control instead of with the flow
of control.
 Control inversion - DI

13. 5. Dependency Injection
13
 High-level modules should not depend on low-level
modules. Both should interact/depend on the
abstraction.
 Abstractions should not depend on details. Details
should depend on abstractions.

14. 5. Dependency Injection
14
Highest level program 6 2
4 12 3 1
- * / -
1
methods
Lowest level program

15. 5. Dependency Injection
15
Highest level program 6 2
4 12 3 1
1
Interface
Lowest level program
- + /

16. 5. Dependency Injection
16
By: Ugonna Thelma

17. 1. Single Responsibility
17
 A module/class should have only one and only one
reason to change.
 Don’t lump functions that change for different
reasons in the same class.
 Don’t mix different concerns in the module.

18. 1. Single Responsibility
18
Employee
Payroll
+ CalcPay
+ Leave
+ Info
Dont!
Dont!

19. 1. Single Responsibility
19
Payroll
Do!
+ CalcPay
Employee
Leave
Info

20. 20
By: Ugonna Thelma

21. 2. Open/Closed
21
 ‘Modules should be open for extension, but closed
for modification’ – Bertrand Meyer
 The high level policy must not know of the low
level details.
 Inheritance – super(parent)
 The super() function in Python makes class inheritance more
manageable and extensible. The function returns a temporary object
that allows reference to a parent class by the keyword super.

22. 22
From: https://www.guru99.com/object-oriented-programming.html

23. 23
By: Ugonna Thelma

24. 3. Liskov Substitution
24
 If S is a subtype of T, then objects of type T in a
program may be replaced with objects of type S
without altering any of the desirable properties of
that program. - Subtypes must be substitutable for
there base types.
 It’s the guideline for using OOP – Inheritance
 IS-A relationship is insufficient and it should be replaced with IS-
Substitutable-For
 By Barbara Liskov in 1987

25. 3. Liskov Substitution
25
Square
Rectangle
Is-a
Geometry: a square is a special type of rectangle because it possesses all the properties of a
rectangle. Similar to a rectangle, a square has: interior angles which measure 90∘ each.
opposite sides that are parallel and equal.

26. 3. Liskov Substitution
26
Square
Rectangle
Is-a
Limitation of the IS-A relationship: Square is not exactly a
rectangle.

27. 27

28. 28

29. 29
Output:
But:
Area of Rectangle = L * B = 10 * 5 = 50

30. 3. Liskov Substitution
30
 IS-Substitutable-For
 use:
 Tell, Don’t Ask Principle: Dont ask for
their type, and then conditionally perform
Actions.

31. 31

32. 32

33. 33

34. 34

35. 35

36. 36
class AreaCalculator:
def calculateArea(self, shapes):
for shape in shapes:
print(f'Area : {shape.width * shape.height}')
square = Square()
square.height = 10
rectangle = Rectangle()
rectangle.width = 10
rectangle.height = 5
shapes = [square, rectangle]
ac = AreaCalculator()
ac.calculateArea(shapes)

37. 37
Output:
Area : 100
Area : 50

38. 38
By: Ugonna Thelma

39. Glossary
39
 References
 https://bit.ly/3q6IeNc by Uncle Bob
 https://bit.ly/2UgdsWq by Sekhar Srinivas
 https://bit.ly/3gJKVjt by Ugonna Thelma

40. Any questions ?
Please send feedbacks about this talk to:
 Anonymous: https://bit.ly/3xj0K7i
 Twitter: @IchDamola
Thanks!
40