O documento discute princípios de design de classes em programação, enfatizando a importância da responsabilidade única e da coesão. Classes devem ser pequenas e focadas, evitando a ambiguidade nas responsabilidades. Além disso, propõe isolamentos de alterações através de abstrações para aumentar a flexibilidade e reutilização do código.

1. Classe
Geovane Pazine Filho
Inael Rodrigues de Oliveira Neto
Jackeline Neves de Almeida

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. 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. Classes pequenas
1ª regra: Classes devem ser pequenas;
2ª regra: Elas devem ser menores ainda.
O quão pequena?

7. Classes pequenas - cont
Cinco métodos nesse caso é muito!!!
Para classe não medimos em quantidade de
métodos e sim responsabilidades!

8. 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".

9. 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.

10. 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.

11. 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?"

12. 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

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

14. 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

15. 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?

16. Coesão
Se convertêssemos aquelas
4 variáveis em instâncias de
classe, seria mais fácil
extrair o código sem passar
variável por parâmetro.

17. Coesão
Se classe ficar com muitas instâncias de
variáveis:
● é bem provável que essa classe pode ser
dividida em outra classe.

18. Como organizar para alterar
● Necessidade de Mudança
○ Complexidade de entendimento das classes
● Mudança constante
○ Risco do Sistema não funcionar como esperado

19. Como organizar para alterar
Exemplo de classe:
● Falta suporte a update
● Modificação tem possibilidade de estragar outro código.

20. 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!

21. 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.

22. 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.

23. 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.

24. Como isolar das alterações
Exemplo:
Classe Portfolio, depende diretamente de
uma API TokyoStockExchange externa para
derivar o valor do portfolio.
Problemas?!

25. Como isolar das alterações
Solução:
Interface StockExchange que declare um único
método.

26. 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"