Livro Código limpo: Classes
-
Upload
inael-rodrigues -
Category
Documents
-
view
966 -
download
3
description
Transcript of Livro Código limpo: Classes
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.)
Encapsulamento
Ideal: variáveis e funções privadas;
Mas para poder realizar testes tornamos protegidas.
Manter a privacidade! Perder o encapsulamento é a última alternativa!
Classes pequenas
1ª 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 responsabilidades!
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 Super
Exercício: Escreva uma breve descrição da classe com 25 palavras sem usar "se", "e", "ou" ou "mas".
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 o oposto não é necessário.
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.
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?"
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
Coesão
No entanto, funções pequenas e poucos parâmetros pode:● proliferar instâncias de variáveis usadas por
vários métodos
Quando isso ocorre deve-se separar as variáveis e métodos em duas classes mais coesas
Coesão
Imagine uma função grande em que desejamos extrair uma parte dela para outra função.
Se código a ser extraído usa quatro variáveis declaradas na função, devemos passar todas as quatro variáveis como parâmetros para a nova função?
Coesão
Se convertêssemos aquelas4 variáveis em instâncias de classe, seria mais fácil extrair o código sem passarvariável por parâmetro.
Coesão
Se classe ficar com muitas instâncias de variáveis:● é bem provável que essa classe pode ser
dividida em outra classe.
Como organizar para alterar
● Necessidade de Mudança○ Complexidade de entendimento das classes
● Mudança constante○ Risco do Sistema não funcionar como esperado
Como organizar para alterarExemplo de classe:
● Falta suporte a update● Modificação tem possibilidade de estragar outro código.
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!
Como organizar para alterar
● Classes comresponsabilidades únicas.
● Metodos privados somenteonde 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.
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.
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.
Como isolar das alterações
Exemplo:Classe Portfolio, depende diretamente de
uma API TokyoStockExchange externa para derivar o valor do portfolio.
Problemas?!