MVC e projeto integrador
Separar regras, apresentação e ações, seguindo um movimento completo e os seus testes.
Papéis
| Papel | Guarda | Não faz |
|---|---|---|
| Model | Estado e invariantes, como limites 0 a 4. | Nada de Swing ou terminal. |
| View | Apresenta estado, encaminha eventos. | Não valida movimentos. |
| Controller | Interpreta ação, pede ao modelo, coordena vista. | Não inventa estado. |
| Montagem | Escolhe implementações e liga objetos. | Não decide regras. |
Variante desta página: controlador atualiza a vista; alternativa usa Observer do modelo para a vista.
Mostrar o estado aceite
Arena 0 a 4, herói em 2:
| Antes | Pedido | Destino | Aceite? | Mostrado |
|---|---|---|---|---|
| 2 | +1 | 3 | Sim | 3 |
| 3 | +2 | 5 | Não | 3 |
| 3 | -1 | 2 | Sim | 2 |
void mover(int deslocamento) {
modelo.mover(deslocamento);
vista.mostrar(modelo.getX());
}
Ler getX() depois da tentativa mostra o aceite, nunca o pedido. (long) x + deslocamento evita overflow antes de validar. Listener Swing só encaminha:
somar.addActionListener(evento -> controlador.mover(1));
O listener curto corre na EDT; o trabalho demorado usa worker e regressa à EDT. Implementação completa.
Testar e integrar
- Modelo sem janela: construção inválida, aceites, ambos os limites, deslocamentos extremos. Recusa conserva a posição.
- Controlador com vista em memória: de 4, pede
+1, espera 4. Só a recusa distingue destino pedido de estado aceite. - Vista: tradução e eventos enviados. Depois, a ligação inteira.
assertEqualsno JUnit;assertde Java exige-ea.- Uma funcionalidade completa primeiro; contratos combinados antes de dividir trabalho; integra cedo. Padrões só perante a variação que resolvem; relatório justifica com código e comportamento preservado.