O documento descreve os 5 princípios do SOLID para desenvolvimento de software, sendo eles: SRP (responsabilidade única), OCP (aberto/fechado), LSP (substituição de Liskov), ISP (segregação de interfaces) e DIP (inversão de dependência), que visam evitar códigos complexos e difíceis de manter.

1. S.O.L.I.D.
Software fácil de manter, extender e reutilizar

2. O que é isso?
Um acrônimo com 5 regras para evitar que o código apodreça?
● SRP - Single Responsability Principle
● OCP - Open Closed Principle
● LSP - Likov Substitution Principle
● ISP - Interface Segregation Principle
● DIP - Dependency Inversion Principle

3. Código apodrecendo?
Você já esteve em um projeto que parecia ficar mais difícil a cada dia?
● Rigidez:
Difícil de mudar o design
● Fragilidade:
Mudar alguma coisa quebra outras em outra parte do sistema
● Imobilidade:
Difícil de reutilizar componentes em outro software
● Viscosidade:
Fazer uma gambiarra é mais fácil do que fazer direito

4. Princípio da responsabilidade única
Toda classe só deve
ter uma responsabilidade,
ou seja, apenas um
motivo para mudar

5. Princípio da responsabilidade única
Alguns benefícios:
● Reusabilidade: Se a classe segue o SRP, será mais fácil reutilizar
● Clareza: O código fica mais simples já que ele não faz nada estranho
● Nomenclatura: Sua classe só faz uma coisa, dar nomes fica mais fácil
● Legibilidade: A classe só faz uma coisa, é clara e tem um bom nome

6. Princípio da responsabilidade única
Não faça isso!

7. Princípio da responsabilidade única
Assim é bem melhor:

8. Princípio do aberto/fechado
Uma classe deve ser
aberta para extensão,
porém fechada
para edição
“Você não precisa fazer uma cirurgia
para vestir um casaco”

9. Princípio do aberto/fechado
E se o cliente quiser desenhar triângulos?

10. Princípio do aberto/fechado
Assim eu não preciso mexer na classe Canvas nunca mais!

11. Não entendi, cadê o triângulo?

13. Princípio da substituição de Liskov
Se q(x) é uma propriedade demonstrável dos
objetos x de tipo T. Então q(y) deve ser
verdadeiro para objetos y de tipo S onde S é um
subtipo de T.

15. Princípio da substituição de Liskov
Classes base devem
poder ser substituídas
por suas classes
derivadas

16. Princípio da substituição de Liskov
Se quebrar posso trocar
por qualquer uma que
encaixe?

17. Princípio da substituição de Liskov

18. Princípio da substituição de Liskov

19. Princípio da substituição de Liskov

20. Princípio da segregação de interfaces
clientes não devem
ser forçados a
depender de
métodos que não
usam.

21. Princípio da segregação de interfaces

22. Princípio da segregação de interfaces

23. Princípio da segregação de interfaces

24. Princípio da segregação de interfaces

25. Ahh, é moleza resolver isso ai...

26. Princípio da segregação de interfaces

27. Princípio da segregação de interface

28. Princípio da segregação de interface

29. Falando Sério

30. Princípio da segregação de interfaces

31. E se eu tiver um cliente que dependa de
duas dessas interfaces?

32. Princípio da segregação de interfaces

33. Princípio da inversão de dependência
A. Módulos de alto nível não deveriam
depender de módulos de baixo nível.
Ambos deveriam depender de
abstrações.
B. Abstrações não deveriam depender
de detalhes. Detalhes devem
depender de abstrações.

34. Princípio da inversão de dependência

35. Obrigado =)