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

5. //
problemas
coesão
● Classe com muitas linhas de código
● Classe é modificada com frequência
● Difícil de entender e manter
● Pouca opção de reuso

6. SOLID

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

8. //
solução (código)
coesão

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

10. //
● O que é?
● Problemas?
● Soluções
● Benefícios
acoplamento

12. Diagrama

13. //
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

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

15. //
solução (código)
acoplamento

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

17. //
● O que é?
● Problemas?
● Soluções
● Benefícios
encapsulamento

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

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

21. //
solução (código)
encapsulamento

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

23. //
● O que é?
● Problemas?
● Soluções
● Benefícios
herança

25. //
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]

26. //
1
solução
herança
2
● LSP (Liskov substitution principle)

27. //
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

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

29. //
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

30. //
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)

31. //
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

32. //
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

33. //
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

34. //
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/

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