The document discusses SOLID principles in object-oriented programming, emphasizing that they are guidelines for class design rather than strict rules. It covers five key principles: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion, each with explanations and examples. The author advocates for flexibility and reusability in code to improve testability and maintainability.

1. SOLID PRINCIPLES
by Steven Ndaye

2. …GROUND RULES…
Solid principles are just bunch of guidelines, not hard and fast
rules
In most cases, we will be required to use our brain and do what
makes sense to us
We also be required to always ask WHY…

3. The SOLID principles are principles of object oriented class design.
Object oriented programming is defined as a method
programming based on a hierarchy of classes, and well-
defined and cooperating objects.

4. …WHY DOES IT MATTER?
You code is going to change. Flexibility will be required
Make your code more reusable(DRY)
Testability
Make out lives easier

5. SOLID PRINCIPLES
Agile Software Development
Principles, Patterns and Practices, by
Robert C.Martin(aka “Uncle Bob”
Martin)

6. SRP
“None but Buddha himself must take the responsibility of giving out occult secrets…”

7. SPR
Cfr project(SRP example1 and example2)
https://github.com/StevenNdaye/solid-principles-session

8. POSSIBLE SRP CODE SMELLS
Long classes(and methods)
God classes

9. LONG CLASSES

10. POSSIBLE SOLUTIONS: LAYERS
UI#
Business'Logic'(Domain'Model)'
Data$Access$
Database'

11. LONG CLASSES
God classes

12. POSSIBLE SOLUTIONS:VERBS

13. Smaller classes and smaller methods will give you more flexibility, and you
don’t have to write much extra code to do it.
SRP matters because we want it to be easy to reuse
code since bigger classes are difficult to change and
harder to read.

14. OCP
“Dutch door. Noun.A door divided in two horizontally so that either part can be left open or closed”

15. Software entities(classes, modules, methods) should be
open for extension but closed for modification…

16. OCP
Cfr project(OCP example1 and example2)
https://github.com/StevenNdaye/solid-principles-session

17. OCP RULE OFTHUMB
Use if/switch if the number of cases is unlikely to change
Use strategy pattern when the number of cases are likely to
change

18. LSP
Subtypes must be substitutable for their base types.

19. Meaning that a subclass should behave nicely when used in place of their
base class.
Functions that use pointers or references to base
classes must be able to use objects of derived classes
without knowing it…

20. ISP
Clients should not be forced to depend on interfaces that they do not use.

21. DIP
Nevermore Let the great interests of the State depend Upon the thousand chances that may sway A piece
of human frailty.

22. High level modules should not depend on low level
modules. Both should depend on abstractions.
Abstractions should not depend upon details. Details
should depend upon abstractions.

23. POSSIBLE SOLUTIONS: LAYER
WITH INTERFACES
UI#
Business'Logic'(Domain'Model)'
Data$Access$
Database'
Interfaces*
Interfaces*

24. Steven Ndaye
THANKYOU
!
For all the examples, please clone this repo @
https://github.com/StevenNdaye/solid-principles-session