Design Patterns
1. MVC (Model–View–Controller)
o Model → regras de negócio e dados (banco de dados, classes de
domínio).
o View → interface que o usuário vê.
o Controller → recebe ações do usuário e decide o que fazer.
Exemplo: No site de hotel, Model é a Reserva, View é a tela de
cadastro, Controller recebe o clique no botão “Reservar”.
2. DAO (Data Access Object)
o Camada que isola o acesso ao banco de dados.
Exemplo: ReservaDAO cuida de insert, update, delete, select da
tabela reservas.
→ Código mais organizado e fácil de trocar de banco no futuro.
3. Builder
o Ajuda a criar objetos complexos passo a passo.
Exemplo: construir um “Pedido” que tem cliente, lista de itens,
endereço, desconto… sem precisar passar tudo no construtor
gigante.
4. Command
o Encapsula uma ação em um objeto.
Exemplo: cada botão de um menu (Salvar, Imprimir, Copiar) vira
um Command. Assim dá para desfazer/refazer ou colocar em fila.
5. Factory
o Classe/método que cria objetos sem expor a lógica de criação.
Exemplo: [Link]("suite") devolve um objeto Suite. O
cliente só pede, não precisa saber como é criado.
SOLID
São 5 princípios para código limpo e flexível:
1. S – Single Responsibility (responsabilidade única)
Cada classe faz uma coisa só.
2. O – Open/Closed
Código deve estar aberto para extensão, fechado para modificação.
3. L – Liskov Substitution
Uma subclasse deve poder substituir a classe pai sem quebrar o
sistema.
4. I – Interface Segregation
Melhor várias interfaces pequenas do que uma gigante.
5. D – Dependency Inversion
Dependa de abstrações (interfaces), não de implementações
concretas.
Object Calisthenics
“Academia para código” 9 regrinhas para treinar boas práticas:
1. Uma classe = uma responsabilidade.
2. Métodos curtos (menos de 50 linhas).
3. Nomes claros e expressivos.
4. Não usar muitos else.
5. Usar objetos, não primitivos “soltos”.
6. Evitar getters/setters desnecessários.
7. Usar coleções pequenas (não listas gigantes manipuladas em todo
lugar).
8. Evitar código duplicado.
9. Sempre pensar em composição ao invés de herança quando possível.
Coesão x Acoplamento
Coesão → quão focado é o propósito de uma classe/módulo.
Classe Reserva só cuida de reservas. Boa coesão.
Acoplamento → quanto uma classe depende de outra.
Se Reserva só funciona se conhecer os detalhes internos de
ClienteDAO, temos acoplamento forte.
O ideal: alta coesão + baixo acoplamento.
Polimorfismo, Herança, Classe Abstrata e Interfaces
Herança: uma classe herda atributos e métodos de outra.
Ex: Cachorro extends Animal.
Classe Abstrata: não pode ser instanciada, serve como modelo com
métodos comuns e outros que devem ser implementados pelas
subclasses.
Ex: abstract class Animal { abstract void emitirSom(); }.
Interface: contrato, só declara métodos, quem implementa é obrigado a
ter esses métodos.
Ex: interface Pagavel { void pagar(); }.
Polimorfismo: um mesmo método pode ter comportamentos diferentes
dependendo do objeto.
Ex: Animal a = new Cachorro(); [Link](); // "Au au"
Animal b = new Gato(); [Link](); // "Miau"
Resumo:
MVC → separar funções (dados, tela, controle).
DAO → acesso ao banco isolado.
Builder → construir objetos complexos.
Command → ação como objeto.
Factory → fábrica de objetos.
SOLID → 5 princípios de código limpo.
Objects Calisthenics → regrinhas de treino de boas práticas.
Coesão alta, acoplamento baixo.
Polimorfismo → mesmo método, diferentes comportamentos.