Classe  Geovane Pazine Filho  Inael Rodrigues de Oliveira Neto  Jackeline Neves de Almeida
Organização              Ordem Variáveis      Públicas (raramente);                Estáticas;                Constantes.  ...
Encapsulamento    Ideal: variáveis e funções privadas;  Mas para poder realizar testes tornamos               protegidas. ...
Classes pequenas1ª regra: Classes devem ser pequenas;2ª regra: Elas devem ser menores ainda.         O quão pequena?
Classes pequenas - cont    Cinco métodos nesse caso é muito!!! Para classe não medimos em quantidade de      métodos e sim...
Classes pequenas - cont O nome da classe descreve quais responsabilidades ela                         faz.Se ela não tiver...
Princípio da Responsabilidade única (SRP)       Uma classe deve ter apenas uma  responsabilidade e um motivo para mudar.A ...
Princípio da Responsabilidade única (SRP)   Responsabilidade única e potencial para     reutilização em outros aplicativos...
Princípio da Responsabilidade única (SRP) "Você quer suas ferramentas organizadas em   caixas de ferramentas com muitas ga...
Coesão● Classes devem ter poucas variáveis● Cada variavel deve ser manipulada por  algum método● Métodos e variáveis são c...
CoesãoVeja a implementação de uma Pilha:● Bem Coesa● Apenas size() não usa ambas as variáveis
CoesãoNo entanto, funções pequenas e poucosparâmetros pode:● proliferar instâncias de variáveis usadas por  vários métodos...
CoesãoImagine uma função grandeem que desejamos extrair umaparte dela para outra função.Se código a ser extraído usa quatr...
CoesãoSe convertêssemos aquelas4 variáveis em instâncias declasse, seria mais fácilextrair o código sem passarvariável por...
CoesãoSe classe ficar com muitas instâncias devariáveis:● é bem provável que essa classe pode ser   dividida em outra clas...
Como organizar para alterar● Necessidade de Mudança  ○ Complexidade de entendimento das classes● Mudança constante  ○ Risc...
Como organizar para alterarExemplo de classe:   ●   Falta suporte a update   ●   Modificação tem possibilidade de estragar...
Como organizar para alterar● A Classe esta logicamente completa?!  ○ Se sim, a classe pode ser deixada em paz!  ○ Se não, ...
Como organizar para alterar●   Classes com    responsabilidades únicas.●   Metodos privados somente    onde necessário.● B...
Como organizar para alterar● Classes devem ser abertas para expansão,  mas fechadas para alteração!● Num sistema ideal, in...
Como isolar das alterações● Uma classe do cliente dependente de  detalhes concretos corre perigo quando tais  detalhes são...
Como isolar das alteraçõesExemplo:  Classe Portfolio, depende diretamente deuma API TokyoStockExchange externa paraderivar...
Como isolar das alteraçõesSolução:Interface StockExchange que declare um único                   método.
Como isolar das alterações● Sistema desacoplado é mais flexivel,  portanto, tem maior capacidade de  reutilização.● Ao uti...
Livro Código limpo:  Classes
Livro Código limpo:  Classes
Próximos SlideShares
Carregando em…5
×

Livro Código limpo: Classes

1.670 visualizações

Publicada em

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

  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

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"

×