Baixo acoplamento e alta coesão no paradigma Orientado a Objetos

Encontre o balanceamento de um sistema pouco acoplado e bem coeso

1. Baixo acoplamento e alta coesão no paradigma Orientado a Objetos "Encontre o balanceamento de um sistema pouco acoplado e bem coeso"

2. Objetivo dessa apresentação? Definição de acoplamento e coesão SOLID Pilares e princípios da orientação a objetos Técnicas e boas práticas Code smells Métricas de código

3. O que é? Problemas? Soluções Benefícios coesão

4. problemas coesão Classe com muit as linhas de código Classe é modificada com frequência Difícil de entender e manter Pouca opção de reuso

5. SOLID

6. 1 solução coesão SRP (Single Responsibility Principle) OCP (Open/closed principle) 2

7. solução (código) coesão

8. benefícios coesão Classes coesas são: mais fáceis de serem mantidas podem ser reutilizadas tendem a ter menos bugs

9. O que é? Problemas? Soluções Benefícios acoplamento

10. Diagrama

11. problemas acoplamento Propagação de mudança Reúso cada vez mais difícil (devido às muitas dependências) Alterações em vários lugares A classe se torna frágil, fácil de quebrar

12. 1 solução acoplamento ISP (Interface segregation principle) DIP (Dependency inversion principle) 2

13. solução (código) acoplamento

14. benefícios Classes pouco acopladas: dependem de menos classes são mais fáceis de serem testadas possuem menos regras de negócio acoplamento

15. O que é? Problemas? Soluções Benefícios encapsulamento

16. problemas encapsulamento Intimidade inapropriada (Code Smell) Cadeia de invocações Aumenta os pontos de mudança

17. 1 solução encapsulamento 2 3 peça ao objeto que tem a informação para fazer o trabalho para você

18. solução (código) encapsulamento

19. benefícios encapsulamento facilidade para alterar a implementação de uma classe menos pontos de mudança (boa propagação de mudança)

20. O que é? Problemas? Soluções Benefícios herança

21. problemas herança usar herança para reaproveitar código, sem questionar se a classe [é um] quebra de encapsulamento operador protected, dá acesso as classes filhas e as [classes do mesmo pacote]

22. 1 solução herança 2 LSP (Liskov substitution principle)

23. solução herança Pré-condições: A classe filha só pode afrouxar as precondições . Ex: classe pai recebe 1-100, a classe filha não pode receber 1-50, pois é mais restritiva 1 2 Pós-condições: A classe filha só pode apertar a pós-condição é o contrário da pré Ex: classe pai retorna 1-100, a classe filha não pode afrouxar 1-200, pois é mais amplo

24. solução (código) herança

25. avalie quando usar herança a composição é mais difícil de quebrar o encapsulamento a composição nos dá flexibilidade de alterar o comportamento de uma classe alterando suas dependências escrever testes é mais fácil herança deve ser usada quando existe a relação de X é um Y e composição é quando a relação é X tem um Y ou X faz uso de Y

26. algumas dicas técnicas e boas práticas evite objetos inválidos ( A própria classe deve garantir que fique em um estado válido, isso pode ser feito utilizando construtores) teorema do bom vizinho tiny types (quando necessário) utilize DTOs que representam pedaços do sistema avalie o uso de objetos imutáveis nomenclatura (procure dar nome legível e de fácil compreensão)

27. más práticas code smells Refused bequest: é quando herdamos de uma classe, mas não queremos fazer uso de alguns dos seus métodos Feature envy: é quando um método está mais interessado em outro objeto do que no objeto em que ele está inserido God class: é aquela classe que controla muitos outros objetos do sistema Divergent changes: é quando a classe não é coesa e sofre alterações constantes, devido às suas diversas responsabilidades Shotgun surgery: é quando surge uma modificação no sistema e para isso é preciso mudar em muitos lugares

28. métricas de código métricas Complexidade ciclomática : é quando ele tem muitas linhas de código ou quando ele tem muitos possíveis diferentes caminhos a serem executados Tamanho de métodos: linhas de código e quantidade de métodos de uma classe LCOM (Lack of cohesion of methods): contabiliza o número do conjunto de diferentes responsabilidades tem uma classe, quanto maior o número menos coesa a classe é Acoplamento eferente: é quando uma classe depende de diversas outras classes Acoplamento aferente: é quando medimos quantas classes dependem da classe principal Má Nomenclatura: procurar seguir o padrão da linguagem

29. resumo conclusão Balancear coesão e acoplamento Programar voltado para interface Depender de classes estáveis Manter o comportamento da classe escondido Favoreça a composição

30. Referências conclusão Livro: Orientação a Objetos e SOLID para Ninjas - Casa do código https://www2.ccs.neu.edu/research/demeter/ https://www.caelum.com.br/apostila-java-orientacao-objetos/heranca-reescrita-e-polimorfismo/ http://blog.caelum.com.br/nao-aprender-oo-getters-e-setters/ http://blog.caelum.com.br/como-nao-aprender-orientacao-a-objetos-heranca/

31. “ Fonte | Santo Agostinho “ Dá o que tens para que mereças receber o que te falta.