Livro Código limpo: Classes

1,152
-1

Published on

Apresentação do capítulo que trata de Classes no Livro - Código Limpo: Habilidades Práticas do Agile Software

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,152
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
37
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Livro Código limpo: Classes

  1. 1. Classe Geovane Pazine Filho Inael Rodrigues de Oliveira Neto Jackeline Neves de Almeida
  2. 2. Organização Ordem Variáveis Públicas (raramente); Estáticas; Constantes. Estáticas privadas; Instância privada; Funções Públicas; Privadas (Após a função pública que a chama.)
  3. 3. Encapsulamento Ideal: variáveis e funções privadas; Mas para poder realizar testes tornamos protegidas. Manter a privacidade! Perder o encapsulamento é a última alternativa!
  4. 4. Classes pequenas1ª regra: Classes devem ser pequenas;2ª regra: Elas devem ser menores ainda. O quão pequena?
  5. 5. Classes pequenas - cont Cinco métodos nesse caso é muito!!! Para classe não medimos em quantidade de métodos e sim responsabilidades!
  6. 6. Classes pequenas - cont O nome da classe descreve quais responsabilidades ela faz.Se ela não tiver um nome conciso, provavelmente ficará grande.Ambiguidade = Chances de muitas responsabilidades. Ex: Processador, Gerenciador ou SuperExercício: Escreva uma breve descrição da classe com 25 palavras sem usar "se", "e", "ou" ou "mas".
  7. 7. Princípio da Responsabilidade única (SRP) Uma classe deve ter apenas uma responsabilidade e um motivo para mudar.A classe abaixo tem 2 motivos para mudar:1º acompanha informação sobre a versão;2º gerencia componentes Swing do Java.Vamos alterar o nro da versão se alterarmos qualquer código Swing, mas ooposto não é necessário.
  8. 8. Princípio da Responsabilidade única (SRP) Responsabilidade única e potencial para reutilização em outros aplicativos. Fazer funcionar é diferente de código limpo!Não terminamos quando o programa funciona!Volte e divida classes muito cheias em outras com responsabilidades únicas.
  9. 9. Princípio da Responsabilidade única (SRP) "Você quer suas ferramentas organizadas em caixas de ferramentas com muitas gavets pequenas, cada um com objetos bem classificados e rotulados? Ou poucas gavetas nas quais você coloca tudo?"
  10. 10. Coesão● Classes devem ter poucas variáveis● Cada variavel deve ser manipulada por algum método● Métodos e variáveis são co-dependentes como um todo lógico
  11. 11. CoesãoVeja a implementação de uma Pilha:● Bem Coesa● Apenas size() não usa ambas as variáveis
  12. 12. CoesãoNo entanto, funções pequenas e poucosparâmetros pode:● proliferar instâncias de variáveis usadas por vários métodosQuando isso ocorre deve-se separar asvariáveis e métodos em duas classes maiscoesas
  13. 13. CoesãoImagine uma função grandeem que desejamos extrair umaparte dela para outra função.Se código a ser extraído usa quatro variáveisdeclaradas na função, devemos passar todasas quatro variáveis como parâmetros para anova função?
  14. 14. CoesãoSe convertêssemos aquelas4 variáveis em instâncias declasse, seria mais fácilextrair o código sem passarvariável por parâmetro.
  15. 15. CoesãoSe classe ficar com muitas instâncias devariáveis:● é bem provável que essa classe pode ser dividida em outra classe.
  16. 16. Como organizar para alterar● Necessidade de Mudança ○ Complexidade de entendimento das classes● Mudança constante ○ Risco do Sistema não funcionar como esperado
  17. 17. Como organizar para alterarExemplo de classe: ● Falta suporte a update ● Modificação tem possibilidade de estragar outro código.
  18. 18. Como organizar para alterar● A Classe esta logicamente completa?! ○ Se sim, a classe pode ser deixada em paz! ○ Se não, devemos considerar consertar nosso projeto!
  19. 19. Como organizar para alterar● Classes com responsabilidades únicas.● Metodos privados somente onde necessário.● Beneficios:● Entendimento Simples!● Risco de uma função prejudicar outra é infima!● Mais fácil testar pontos lógicos● Adicionar funções muito mais fácil.
  20. 20. Como organizar para alterar● Classes devem ser abertas para expansão, mas fechadas para alteração!● Num sistema ideal, incorporaríamos novos recursos através da expansão e não alterando o código.
  21. 21. Como isolar das alterações● Uma classe do cliente dependente de detalhes concretos corre perigo quando tais detalhes são modificados.● Interface e classes abstratas ajudam a isolar o impacto desses detalhes.
  22. 22. Como isolar das alteraçõesExemplo: Classe Portfolio, depende diretamente deuma API TokyoStockExchange externa paraderivar o valor do portfolio. Problemas?!
  23. 23. Como isolar das alteraçõesSolução:Interface StockExchange que declare um único método.
  24. 24. Como isolar das alterações● Sistema desacoplado é mais flexivel, portanto, tem maior capacidade de reutilização.● Ao utilizar dessa estratégia nossas classes aderem ao DIP (Principio da Inversão da Independencia)"Classes devem depender de abstrações e não de detalhes concretos"

×