This document provides an overview of the SOLID principles for designing maintainable object-oriented code. It discusses each principle - Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion - and gives examples of how to apply them. The principles aim to create code that is flexible, reusable, and understandable by dividing programs into independent parts that are easy to maintain and modify. The document stresses that code should be written for humans to read and change, keep things simple, and use object-oriented best practices like design patterns and low coupling.

1. S.O.L.I.D
Overview

2. What is S.O.L.I.D?
About making a better code

3. Why do we need a good design?
● to deliver faster
● to manage change easily
● to deal with complexity
● to keep maintainable

4. The psychology reason - Broken Window theory:
The psychology reason -
Broken Window theory
A broken window will trigger a building into a smashed and
abandoned derelict

6. What is a bad code?
● Complex
● Repetition
● Hard to read
● Needs to be explained

7. How can you identify a bad code?
Design Smells
● Rigidity
● Fragility
● Immobility
● Viscosity
● Needless Complexity
● Needless Repetition

8. Rigidity
● Hard to change
● Hard to predict how much time will take to change
● Needs to change a lot of parts (cascate)
● High coupling

9. Fragility
● Breaks easily
● One change breaks many differents places (Modules)
● Collateral effect
● Fear of change

10. Immobility
● Does not favor reuse
● It contains parts that could be useful in other systems, but the effort and risk of
separating them from the original system are too great

11. Viscosity
● Caused by work around
● When it is more difficult to change using good designs than using hacks
● It is easier to skip the processes than to follow them (Skip unit tests)

12. Needless Complexity
● Hard to read
● Hard to understand
● Code not used

13. Needless repetition
● Copy and Paste instead of isolate and reuse
● Don’t use abstraction

14. S.O.L.I.D
Principles

15. Single Responsibility
Principle

16. Single Responsibility
● Extremely connected with cohesion
● A class should have only one reason to change
● Encapsulate the responsibility
● Violations
○ Difficult to name clearly using single verb
○ Boolean flags
○ Too many lines (methods and classes)
○ Hard to define the scope of unit test

18. Applying
Principle

20. Open/Close
Principle

21. Open/Close
● Providing extension capacity, so that it is not necessary to change what is
already implemented (when possible)
● Using abstraction
● Does not exist project 100% closed, create strategic point of extension
● Keeping fields (members) encapsulated (private)
● Avoiding global variables
● Design Patterns friends:
○ Abstract factory
○ Visitor
○ Decorator
○ Strategy

23. Applying
Principle

25. https://docs.google.com/presentation/d/15gyVPZRXt57zhagiMP3yDDSrKHBNq93K
hYw7w7dsOoQ/edit#slide=id.g249e99ff54_0_1

27. Liskov Substitution
Principle

28. Liskov Substitution
● Programming for interface not to implementation
● Subclass should be able to be changed by your base class and behave
properly without side effects
● Strictly related with coupling
● Violations:
○ Subclasses that do not provide implementations to all abstract methods
(UnsupportedMethodsExceptions, empty methods)
○ Instanceof checks

29. Interface Segregation
Principle

30. Interface Segregation
● Programming to behave
● Related with single responsibility
● Avoiding big interfaces
● Client just has to know his needs (what is essential)

35. Applying
Principles

40. Dependency inversion
Principle

41. Dependency inversion
● High-level modules should not depend on low-level modules
● Abstractions should not depend on other details
● Both should depend on abstractions
● To ensure that the configuration of services is separated from their use
● Design Patterns friends:
○ Inversion of Control Principle (Don't call us, we'll call you)
○ Factory Method
○ Abstract Factory
○ Prototype
○ Iterator
○ Service Locator
○ Template Methods

43. Applying
Principles

46. Think about abstraction

47. Yes, but...

48. Conclusion

49. Conclusion
● The first thing to take in consideration is that we develop code to humans read
● The second one is to attend the propose
● KISS (Keep It Simple Stupid)
● Use OOP principles like:
○ Reusability
○ Design Patterns
○ High cohesion
○ Low coupling
○ DRY (Don't repeat yourself)
● Other principles and references to help you
○ TDD (it is not only about test, but about design)
○ Clean Code
○ Clean Architecture
○ DDD

50. Bibliography

51. Bibliography
● OOD Principles - Uncle Bob
● http://en.wikipedia.org
● http://www.oodesign.com
● https://www.infoq.com/solid/
● https://martinfowler.com/articles
● https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy