Livro Código limpo: Classes

Classe

Geovane Pazine FilhoInael Rodrigues de Oliveira NetoJackeline Neves de Almeida

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

Veja a implementação de uma Pilha:● Bem Coesa● Apenas size() não usa ambas as variáveis

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?!

Como isolar das alterações

Soluçã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 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"