📝 Exercícios Práticos - Aula 02
💻 Duração: 30 minutos
🎯 Objetivos
Ao completar estes exercícios, você será capaz de:
- Identificar código duplicado em sistemas reais
- Extrair validadores reutilizáveis seguindo princípio DRY
- Centralizar regras de negócio de forma testável
- Aplicar checklist de qualidade de reuso
📋 Exercício 1: Identificar e Eliminar Duplicação (15 min)
Problema:
Refatore a classe abaixo eliminando a duplicação de código sem quebrar a funcionalidade:
public class PedidoService {
public void validarPedido(Pedido pedido) {
if (pedido.getEmail() == null || !pedido.getEmail().contains("@")) {
throw new IllegalArgumentException("Email inválido");
}
System.out.println("Pedido validado");
}
public void validarCliente(Cliente cliente) {
if (cliente.getEmail() == null || !cliente.getEmail().contains("@")) {
throw new IllegalArgumentException("Email inválido");
}
System.out.println("Cliente validado");
}
public void validarFornecedor(String emailFornecedor) {
if (emailFornecedor == null || !emailFornecedor.contains("@")) {
throw new IllegalArgumentException("Email inválido");
}
System.out.println("Fornecedor validado");
}
}Requisitos da Refatoração:
- Criar classe
EmailValidatorcom método estático - Eliminar toda duplicação de validação de e-mail
- Manter exatamente a mesma funcionalidade
- Usar nomes descritivos seguindo Aula 01
- Adicionar documentação JavaDoc apropriada
Dicas de Implementação:
- Analise o código: Que parte está duplicada exatamente?
- Extraia a regra: Crie método static
validarOuFalhar(String email) - Substitua todas as ocorrências: Use o validador nos 3 métodos
- Teste manualmente: Comportamento deve ser idêntico
📋 Exercício 2: Criar Validador Completo (15 min)
Problema:
Crie uma classe CpfValidator seguindo o padrão do EmailValidator já visto na aula:
// Sua implementação deve permitir este uso:
CpfValidator.validarOuFalhar("123.456.789-01"); // OK
CpfValidator.validarOuFalhar("111.111.111-11"); // Lança exceção
CpfValidator.isValido("12345678901"); // Retorna true/false
CpfValidator.formatar("12345678901"); // "123.456.789-01"Regras de Negócio:
- CPF deve ter exatamente 11 dígitos (após limpeza)
- Não aceitar CPF com todos os dígitos iguais (ex: 111.111.111-11)
- Aceitar CPF com ou sem formatação (pontos e hífens)
- Normalizar removendo formatação para armazenamento
- Formatar no padrão XXX.XXX.XXX-XX para exibição
Métodos Obrigatórios:
public static void validarOuFalhar(String cpf)
public static boolean isValido(String cpf)
public static String limparFormatacao(String cpf)
public static String formatar(String cpf)
public static String normalizar(String cpf)Casos de Teste para Validar:
// ✅ DEVEM PASSAR:
"12345678901"
"123.456.789-01"
"123 456 789-01"
" 123.456.789-01 "
// ❌ DEVEM FALHAR:
null
""
"123456789" // Muito curto
"123456789012" // Muito longo
"111.111.111-11" // Dígitos repetidos
"00000000000" // Zeros repetidos
"123456789AB" // Com letras⏱️ Atividade Rápida Final (5 min)
Escolha UM dos exercícios acima e:
- Implemente sua solução completa
- Teste rapidamente com 3 casos (válido, inválido, edge case)
- Prepare apresentação de 2 minutos explicando:
- Que duplicação você identificou
- Como centralizou a regra
- Por que sua solução é melhor
Critérios de Avaliação:
- ✅ DRY aplicado: Eliminação efetiva de duplicação
- ✅ Reutilização: Solução pode ser usada em outros contextos
- ✅ Testabilidade: Fácil de criar testes unitários
- ✅ Legibilidade: Código claro seguindo Aula 01
🎯 Checklist de Qualidade DRY
Antes de finalizar, verifique:
📋 Eliminação de Duplicação:
- Identifiquei toda a lógica duplicada?
- Extraí para um local único e bem localizado?
- Todas as ocorrências agora usam o componente centralizado?
🔧 Qualidade da Solução:
- Validador é reutilizável em outros contextos?
- Nome da classe/método indica claramente a responsabilidade?
- Regra centralizada é fácil de testar isoladamente?
- Fácil de evoluir quando regra mudar?
⚡ Benefícios Práticos:
- Bug fix em um local corrige em todos os usos?
- Nova funcionalidade pode reusar automaticamente?
- Time sabe onde encontrar e onde evoluir a regra?
🔗 Arquivos Relacionados
📂 Para Consulta:
- Exemplo base:
projeto-pratico/src/main/java/aula02/ExemploAntes.java - Solução referência:
projeto-pratico/src/main/java/aula02/EmailValidator.java - Gabarito completo:
projeto-pratico/src/main/java/aula02/GabaritoExercicios.java
🧪 Para Teste:
- Testes EmailValidator:
projeto-pratico/src/test/java/aula02/EmailValidatorTest.java - Testes CpfValidator:
projeto-pratico/src/test/java/aula02/CpfValidatorTest.java
⚡ Para Execução:
# Compilar e testar
cd projeto-pratico
mvn test -Dtest=EmailValidatorTest
mvn test -Dtest=CpfValidatorTest
# Ou no IDE: Run as JUnit Test💡 Conexão com Próximas Aulas
Estes exercícios preparam você para:
🎯 Aula 03 - Refatoração Segura:
- Componentes testáveis criados aqui serão refatorados com segurança
- Testes unitários garantirão que refatoração não quebra funcionalidade
- Regras centralizadas facilitam mudanças estruturais
📈 Projetos Reais:
- Validação consistente em sistemas corporativos
- Redução de bugs por inconsistência de regras
- Facilidade de manutenção quando regras evoluem
- Base para automação de testes de regressão
🚨 Problema Comum e Solução
❌ “Minha validação está muito simples”
Resposta: Perfeito! Validação simples é validação testável e compreensível. Na vida real, você vai partir dessa base e evoluir incrementalmente conforme necessidade.
❌ “E se eu precisar de validação mais complexa?”
Resposta: Princípio DRY escala! Quando precisar, você:
- Evolui o validador existente
- Todos os usos recebem a melhoria automaticamente
- Testa a evolução uma vez só
- Confia que comportamento é consistente
✅ O importante é o princípio:
- Uma regra = Um local de manutenção
- Mudança = Um ponto de alteração
- Teste = Um local de validação
- Evolução = Benefício para toda aplicação