O documento explica os princípios SOLID da programação orientada a objetos, definidos por Robert C. Martin. Os cinco princípios visam promover a manutenção de código limpo, coeso e de fácil entendimento, garantindo que cada classe tenha uma única responsabilidade. A adesão a esses princípios ajuda no desenvolvimento de sistemas que são abertos para extensão e fechados para modificação.

1. E o solid?

2. Hello!Evelise Vazquez - Desenvolvedora Front-end na equipe Labs
Eu vim de Santos, fã de Charlie Brown e péssima jogadora de DOOM
nas horas vagas
Medium e Twitter - @EveliseVazquez
2

3. SOLID é um acrônimo criado por
Michael Feathers que representa
os 5 princípios da programação
orientada a objetos identificados
por Robert Cecil Martin ou Uncle
Bob nos princípios de 2000.
3

4. S.Single Responsibility Principle
4

5. × A classe deve ter somente um motivo para ser
modificada.
× Cada responsabilidade deve ser uma classe e
cada classe deve ter uma única
responsabilidade.
5

6. 6
Classe com muitas responsabilidades:
× Validar dados do cliente
× Gerar Imposto
× Salvar cupom fiscal
× Imprimir cupom fiscal
× Enviar cupom por email

7. 5 responsabilidades =>
5 motivos para ser
modificada.
7

8. × A falsa impressão de que o sistema está sendo
construído de forma prática e simples, por
conter poucas classes para manutenção.
× A medida que o sistema cresce, a dificuldade
aumenta.
8

9. 9

10. 10

11. × Facilidade de manutenção
× Código limpo e de fácil entendimento
× Redução do acoplamento (dependências)
× Complexidade reduzida
× Coesão das classes
11

12. O.Open Closed Principle
12

13. Você deve ser capaz de
estender um
comportamento de uma
classe sem a necessidade
de modificá-lo
13

14. × Abertas para extensão, fechadas para
modificação
× Modificação através de: herança, interface ou
composição
14

15. 15

16. 16

17. A ideia é criarmos novas classes para
funcionalidades de tipos
semelhantes
17

18. 18
Fechada
Aberta

19. L.Liskov Substitution Principle
19

20. As classes derivadas devem
ser substituíveis por suas
classes bases
20

21. 21

22. 22
Não faz sentido essa
extensão

23. 23

24. I.Interface Segregation Principle
24

25. Classes não devem ser
forçadas a depender de
interfaces que elas não
usam.
25

26. 26

27. 27

28. Interfaces que têm muitos
comportamentos , além de quebrar
o primeiro princípio de Single
Responsability, dificulta a
manutenção do código
28

29. 29

30. × Separando cada interface com a sua
responsabilidade única.
× Caso eu precise adicionar uma nova
funcionalidade no celular, eu vou alterar
apenas uma classe.
30

31. D.Dependency Inversion Principle
31

32. Dependa de abstrações e
não de implementações.
32

33. × Depender de abstrações facilita a mudança
por conter menos alterações do que uma
classe.
33

34. 34

35. 35
Eu ODEIO
mexer
no seu
código
Você não
segue o SOLID

36. 36

37. × A ideia de usar o SOLID é ideal para manter
uma arquitetura de código legível e de fácil
manutenção
× Por ser um padrão, qualquer pessoa que
entra em contato com o projeto consegue
caminhar sozinha
37