DEV Community: Diego de Sousa Brandão

Migração do Java 11 para Java 17: Benefícios e Trade-offs com Evidências Técnicas

Diego de Sousa Brandão — Sun, 07 Sep 2025 18:45:03 +0000

Índice

Resumo
Benefícios da Migração
- 1.1 Melhorias de Performance
- 1.2 Novos Recursos de Linguagem
- 1.3 Melhorias de Segurança
- 1.4 Suporte Long-Term Support (LTS)
Trade-offs e Desafios
- 2.1 Questões de Compatibilidade
- 2.2 Desafios Específicos da Migração
- 2.3 Custos de Migração
Casos de Estudo Reais
- 3.1 Salesforce
- 3.2 Halodoc
Recomendações Práticas
- 4.1 Estratégia de Migração
- 4.2 Alternativas Graduais
Conclusão
Referências

Resumo

A migração do Java 11 para Java 17 representa uma atualização estratégica significativa para aplicações enterprise. Java 17 é uma versão Long-Term Support (LTS) que oferece melhorias substanciais em performance, segurança e recursos de linguagem, com suporte Oracle Premier até setembro de 2026. Este artigo apresenta uma análise técnica baseada em evidências sobre os benefícios e trade-offs desta migração.

Estudos de benchmark demonstram ganhos de performance de 6-26% com Java 17, enquanto novos recursos como Records, Sealed Classes e melhor tratamento de NullPointerException melhoram significativamente a produtividade do desenvolvedor. Os principais trade-offs incluem questões de compatibilidade com bibliotecas legadas e a necessidade de atualização de dependências.

1. Benefícios da Migração

1.1 Melhorias de Performance

Evidências de Benchmark Independentes

A OptaPlanner conduziu benchmarks extensivos comparando Java 11, 16 e 17, utilizando hardware estável (Intel Xeon Silver 4116 @ 2.1 GHz, 128 GiB RAM) em problemas de otimização reais durante 5 minutos cada. Os resultados demonstraram melhorias consistentes de performance.

A Azul Systems reportou em benchmarks de 2025 que OpenJDK 17 foi 6% mais rápido que a baseline, enquanto soluções otimizadas como Azul Platform Prime alcançaram 26% de melhoria.

Melhorias no Garbage Collection

Java 17 introduz melhorias no garbage collector, particularmente em situações de baixa memória, resultando em ganhos de performance para aplicações que lidam com grandes datasets ou operações intensivas de memória.

O G1 garbage collector tornou-se padrão a partir do Java 9, oferecendo performance mais consistente e tempos de resposta mais previsíveis. ZGC (Z Garbage Collector) tornou-se production-ready no JDK 17, oferecendo coleta de lixo de baixa latência (sub-10ms) para heaps de até vários terabytes. Shenandoah está disponível em builds específicos como Red Hat OpenJDK e Amazon Corretto, mas não faz parte do Oracle JDK oficial.

1.2 Novos Recursos de Linguagem

Records

Records permitem criar classes de dados imutáveis especificando apenas os campos necessários; todos os outros métodos são gerados automaticamente. Records atuam como classes de dados onde todos os campos são final, garantindo imutabilidade da referência. Importante: Records são imutáveis por contrato apenas se usados com tipos imutáveis. O fato dos campos serem final garante imutabilidade da referência, mas não garante thread-safety absoluto se o campo for um objeto mutável.

// Java 11 - Classe tradicional
public class DataClass {
    private final Integer id;
    private final String name;

    public DataClass(Integer id, String name) {
        this.id = id;
        this.name = name;
    }

    public Integer getId() { return id; }
    public String getName() { return name; }

    @Override
    public boolean equals(Object o) { /* implementação */ }
    @Override
    public int hashCode() { /* implementação */ }
}

// Java 17 - Record
public record DataClass(Integer id, String name) {}

// Cuidado: Records com objetos mutáveis
public record PersonRecord(String name, List<String> hobbies) {}

PersonRecord person = new PersonRecord("João", new ArrayList<>());
person.hobbies().add("futebol"); // Modifica o estado interno!
// Para verdadeira imutabilidade, use List.copyOf() ou Collections.unmodifiableList()

Sealed Classes

Sealed Classes foram adicionadas à linguagem Java, restringindo quais outras classes ou interfaces podem estendê-las ou implementá-las, melhorando a segurança de tipos e organização do código.

Pattern Matching e Switch Expressions

Switch expressions melhoradas permitem sintaxe mais concisa e segura. O operador instanceof também foi aprimorado, permitindo verificação de tipo e cast em uma única linha. A principal vantagem é legibilidade e segurança de tipo, eliminando a necessidade de casts explícitos e reduzindo a possibilidade de ClassCastException.

Melhor Tratamento de NullPointerException

Uma atualização incrivelmente útil no Java 17 são as NullPointerExceptions melhoradas! Finalmente, nos logs de stack trace, é possível ver qual campo específico causou a NullPointerException.

// Java 17 - NPE melhorada
String s = null;
System.out.println(s.toLowerCase());

// Exception output:
// java.lang.NullPointerException: Cannot invoke "String.toLowerCase()" 
// because "s" is null

1.3 Melhorias de Segurança

Atualizações Regulares de Segurança

O modelo de lançamento de segurança Java mudou para estar alinhado com o cronograma Oracle Critical Patch Update (CPU), onde releases CPU são lançados na terceira terça-feira de janeiro, abril, julho e outubro.

JDK 17 introduziu melhorias significativas de segurança incluindo modo de validação segura XML habilitado por default, algoritmos SHA-1 desabilitados por padrão em assinaturas XML, e melhorias no suporte OCSP com requisições HTTP GET para performance.

Encapsulamento Forte de Internals do JDK

JEP 403 fortalece o encapsulamento de internals do JDK. Java 17 é fortemente encapsulado por padrão, então reflexão para internals do JDK não é mais permitida. Código que acessa campos e métodos não-públicos de APIs java.* lançará InaccessibleObjectException.

1.4 Suporte Long-Term Support (LTS)

Java 17 é uma versão LTS com Oracle Premier Support até setembro de 2026, proporcionando estabilidade e atualizações de segurança por período estendido. O processo de LTS garante que essas versões tornem-se mais estáveis e seguras devido a correções de bugs, melhorias de performance e patches de segurança.

2. Trade-offs e Desafios

2.1 Questões de Compatibilidade

Deprecação e Remoção de APIs

Provavelmente a mudança mais significativa relacionada à segurança no JDK 17 é JEP 411: Deprecate the Security Manager for Removal. JDK 17 inicia esse processo depreciando várias APIs do Security Manager.

Vários parâmetros JVM foram removidos ou depreciados até o Java 17. Se sua aplicação dependia das funcionalidades experimentais AOT ou Graal JIT no Java 11, considere a transição para GraalVM.

Problemas com Bibliotecas de Terceiros

Nem todas as bibliotecas e frameworks de terceiros têm garantia de suporte ao Java 17 imediatamente. Verificar compatibilidade e atualizações é crucial. Ferramentas de build (Maven, Gradle) e IDEs devem ser atualizadas para suportar Java 17.

2.2 Desafios Específicos da Migração

Problemas com Lombok

Um problema recorrente em migrações é incompatibilidade com versões antigas do Lombok. Um erro comum é:

java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor cannot access class com.sun.tools.javac.processing.JavacProcessingEnvironment

A solução prática é atualizar o Lombok para uma versão compatível (por exemplo, >= 1.18.22) e validar a compilação/annotation-processing em ambientes CI e locais. Em casos extremos, configure o --add-opens temporariamente apenas para testes, mas prefira atualizar bibliotecas e remover dependências de internals.

Configuração de Garbage Collection

Embora coletores de lixo mais novos como G1 ofereçam melhor performance, eles podem requerer ajustes. Aplicações com configurações customizadas de GC precisarão revisitar essas configurações.

Modularização (Opcional)

Importante: A modularização NÃO é obrigatória para Java 17. Aplicações podem continuar usando o classpath tradicional exatamente como em Java 11. A migração para o Module System (JPMS) é completamente opcional e só deve ser considerada se você quiser benefícios específicos como:

Encapsulamento mais forte de pacotes internos
Dependências explícitas entre módulos
Redução de footprint de memória em aplicações modulares

A grande maioria das aplicações enterprise pode migrar para Java 17 sem qualquer mudança no sistema de módulos.

2.3 Custos de Migração

Testes Extensivos Necessários

Antes de migrar microserviços Java do JDK 11 para JDK 17, é essencial garantir que todos os testes unitários, de integração e de sistema passem com sucesso. Este passo é necessário para verificar que a aplicação funciona como esperado.

Tempo de Desenvolvimento

A Salesforce reportou que a migração do JDK 11 para JDK 17 levou três anos de planejamento com sete meses de desenvolvimento ativo. Importante: Este prazo reflete o tamanho massivo do ecossistema Salesforce (Sales Cloud, Service Cloud, Marketing Cloud) com milhares de aplicações e microserviços. Empresas menores terão prazos significativamente mais curtos - a maioria das organizações pode completar a migração em algumas semanas ou meses, dependendo da complexidade da arquitetura.

No entanto, as lições aprendidas pela Salesforce permitirão que futuras migrações, como JDK 21, sejam completadas em apenas um ano, demonstrando o valor do aprendizado organizacional.

3. Casos de Estudo Reais

3.1 Salesforce

A Salesforce liderou uma migração desafiadora do JDK 11 para JDK 17 para garantir performance e escalabilidade das aplicações principais, incluindo Sales Cloud, Service Cloud e Marketing Cloud. A migração entregou melhorias significativas de performance, possibilitando processamento mais rápido.

3.2 Halodoc

A Halodoc migrou seus microserviços backend Java do JDK 11 para JDK 17, enfrentando desafios específicos como conflitos entre dependências Redisson e Jackson, que foram resolvidos através de cuidadoso exame das versões de dependências e ajustes necessários para garantir compatibilidade.

4. Recomendações Práticas

4.1 Estratégia de Migração

Análise de Dependências: Analisar dependências do projeto para garantir compatibilidade com Java 17. Atualizar bibliotecas ou frameworks desatualizados para versões que suportem a nova versão Java.
Ambiente de Testes: Testar aplicação em ambiente especial de testes com JDK atualizado. Revisar e atualizar todas as dependências e ferramentas de build para versões compatíveis com JDK 17.
Análise Estática: Executar verificação estática de código para identificar onde problemas podem ocorrer. Ferramentas como Checkstyle, PMD, ou SpotBugs podem ser utilizadas.

4.2 Alternativas Graduais

Para organizações não prontas para migração completa, alguns fornecedores de JDK oferecem soluções otimizadas que podem combinar versões de API com JVMs mais recentes. É recomendável avaliar benchmarks específicos para seu caso de uso antes de adotar soluções comerciais que prometem melhorias de performance específicas.

5. Conclusão

A migração do Java 11 para Java 17 oferece benefícios substanciais e mensuráveis:

Benefícios Principais:

Melhorias de performance de 6-26% conforme benchmarks independentes
Recursos de linguagem modernos como Records, Sealed Classes e melhor tratamento de exceções (NPE melhoradas desde Java 14)
Melhorias significativas de segurança e encapsulamento forte
Suporte LTS: Oracle Premier até 2026, Extended até 2029, com alternativas de suporte de outros fornecedores
ZGC production-ready para aplicações que necessitam baixa latência

Trade-offs Principais:

Necessidade de atualização de dependências e ferramentas
Problemas específicos com bibliotecas como Lombok
Investimento em tempo de desenvolvimento e testes
Configurações de GC podem requerer ajustes dependendo do perfil da aplicação

Graças à forte compatibilidade retroativa do Java, a migração do 11 para o 17 tende a ser incremental e de baixo risco, especialmente em comparação com saltos maiores (ex: 8 → 17). A compatibilidade permite mudar para Java 17 sem alterações de código obrigatórias (modularização é opcional) e aproveitar todos os recursos atualizados. A versão 17 é Long-term Support, garantindo atualizações de segurança por período estendido com múltiplas opções de fornecedores.

Para organizações enterprise, a migração é altamente recomendada, especialmente considerando que aplicações de grande escala e alta carga verão definitivamente melhor performance, tempo de inicialização mais rápido e menor footprint de memória após a migração.

6. Referências

HashStudioz Technologies. (2024). Java Project Migration: Step-by-Step Guide from Java 11 to 17. Retrieved from https://www.hashstudioz.com/blog/java-11-to-java-17-migration-guide/
Bell-SW. (2024). How to Migrate from Java 11 to Java 17: Step-by-Step Tutorial. Retrieved from https://bell-sw.com/blog/migration-from-java-11-to-java-17/
HackerNoon. (2023). Is Migrating From Java 11 to Java 17 Worth It? Retrieved from https://hackernoon.com/is-migrating-from-java-11-to-java-17-worth-it
Medium - Pradeep Chirumamilla. (2024). Java 11 to Java 17 Migration: A Guide with Key Features and Code Implementation. Retrieved from https://medium.com/@pradeepchirumamilla01/java-11-to-java-17-migration-a-guide-with-key-features-and-code-implementation-dd63e0bd79e3
Halodoc Engineering. (2023). A Practical Guide to Migrating from JDK 11 to JDK 17. Retrieved from https://blogs.halodoc.io/jdk-17-migration/
Zenesys. (2024). Migrating a Project From Java 11 to Java 17: A Step-by-Step Guide. Retrieved from https://www.zenesys.com/migrating-a-project-from-java-11-to-java-17-a-step-by-step-guide
Medium - Alex Klimenko. (2025). Migrating from Java 8 to Java 17: What Changed and Potential Issues. Retrieved from https://medium.com/@alxkm/migrating-from-java-8-to-java-17-what-changed-and-potential-issues-85d2e85fc1ca
DEV Community - NIX. (2022). Migrating a Project From Java 11 to Java 17: A Step-by-Step Guide for Developers. Retrieved from https://dev.to/nix/migrating-a-project-from-java-11-to-java-17-a-step-by-step-guide-for-developers-42n
Salesforce Engineering. (2025). Behind Salesforce's JDK 11 to JDK 17 Migration. Retrieved from https://engineering.salesforce.com/behind-salesforces-jdk-11-to-jdk-17-migration-lessons-for-modernizing-large-scale-java-applications/
Medium - Alex Klimenko. (2024). Modernizing Legacy Java: A Practical Guide to Migrating to Java 17/21+. Retrieved from https://medium.com/@alxkm/modernizing-legacy-java-a-practical-guide-to-migrating-to-java-17-21-b3ab6a215f1f
OptaPlanner. (2021). How much faster is Java 17? Retrieved from https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html
Oracle. (2021). JDK 17 Release Notes, Important Changes, and Information. Retrieved from https://www.oracle.com/java/technologies/javase/17-relnote-issues.html
GitHub - Ionut Balosin. (2024). JVM Performance Benchmarks. Retrieved from https://github.com/ionutbalosin/jvm-performance-benchmarks
Azul Systems. (2025). Benchmarks Show Faster Java Performance Improvement. Retrieved from https://www.azul.com/blog/benchmarks-show-faster-java-performance-improvement/
Oracle. (2014). Avoiding Benchmarking Pitfalls on the JVM. Retrieved from https://www.oracle.com/technical-resources/articles/java/architect-benchmarking.html
oj! Algorithms. (2022). JDK17 Benchmark. Retrieved from https://www.ojalgo.org/2021/11/jdk17-benchmark/
Oracle. (2024). Overview of Java SE Subscription Enterprise Performance Pack. Retrieved from https://docs.oracle.com/en/java/java-components/enterprise-performance-pack/epp-user-guide/overview.html
Ionut Balosin. (2023). JVM Performance Comparison for JDK 17. Retrieved from https://ionutbalosin.com/2023/03/jvm-performance-comparison-for-jdk-17/
Pretius. (2022). Java 17 features: A comparison between versions 8 and 17. Retrieved from https://pretius.com/blog/java-17-features
Oracle. (2021). JDK Releases. Retrieved from https://www.java.com/releases/
Oracle. (2024). Consolidated JDK 17 Release Notes. Retrieved from https://www.oracle.com/java/technologies/javase/17all-relnotes.html
Oracle. (2025). Oracle Java SE Support Roadmap. Retrieved from https://www.oracle.com/java/technologies/java-se-support-roadmap.html
Baeldung. (2024). New Features in Java 17. Retrieved from https://www.baeldung.com/java-17-new-features
Oracle. (2024). Java™ SE Development Kit 17, 17.0.15 Release Notes. Retrieved from https://www.oracle.com/java/technologies/javase/17-0-15-relnotes.html
Oracle. (2024). Java Security Resource Center. Retrieved from https://www.oracle.com/java/technologies/security.html
Wikipedia. (2025). Java version history. Retrieved from https://en.wikipedia.org/wiki/Java_version_history
Sean Mullan. (2021). JDK 17 Security Enhancements. Retrieved from https://seanjmullan.org/blog/2021/09/14/jdk17
Red Hat. (2024). OpenJDK Life Cycle and Support Policy. Retrieved from https://access.redhat.com/articles/1299013
Oracle. (2021). Java Platform, Standard Edition Oracle JDK Migration Guide, Release 11. Retrieved from https://docs.oracle.com/en/java/javase/11/migrate/index.html
Oracle. (2024). Migrating From JDK 8 to Later JDK Releases. Retrieved from https://docs.oracle.com/en/java/javase/17/migrate/migrating-jdk-8-later-jdk-releases.html

Java Records vs Lombok: Guia Definitivo para Escolher a Ferramenta Certa

Diego de Sousa Brandão — Mon, 21 Jul 2025 23:23:42 +0000

Introdução

A eterna busca por reduzir o código boilerplate em Java ganhou duas ferramentas poderosas: Java Records (introduzidos no Java 14 e estabilizados no Java 16) e Lombok (biblioteca amplamente adotada há anos). Embora ambos ataquem o mesmo problema - a verbosidade do Java - eles fazem isso de maneiras fundamentalmente diferentes, com implicações importantes para o design e arquitetura do seu código.

Este artigo vai além da comparação superficial de sintaxe e mergulha nas diferenças semânticas, casos de uso práticos e trade-offs de cada abordagem.

Records Java: Mais que Redução de Boilerplate

O que são Records?

Records não são apenas uma forma concisa de criar classes - eles são tipos de produto com semântica específica. Segundo a JEP 395:

"Records são portadores transparentes de dados imutáveis"

A palavra-chave aqui é transparente. Records seguem o princípio:

"A API de um record modela o estado, todo o estado, e nada além do estado"

Exemplo Básico

// Antes: 40+ linhas de código boilerplate
public class Pessoa {
    private final String nome;
    private final int idade;

    public Pessoa(String nome, int idade) {
        this.nome = nome;
        this.idade = idade;
    }

    public String getNome() { return nome; }
    public int getIdade() { return idade; }

    @Override
    public boolean equals(Object o) { /* implementação */ }
    @Override
    public int hashCode() { /* implementação */ }
    @Override
    public String toString() { /* implementação */ }
}

// Depois: 1 linha
public record Pessoa(String nome, int idade) {}

Características dos Records

Imutabilidade por Design: Todos os campos são private final
Transparência: Não há estado oculto
Construtores Canônicos: Gerados automaticamente
Métodos Padrão: equals(), hashCode(), toString() implementados automaticamente
Acessores: Métodos com o mesmo nome dos componentes

Lombok: Flexibilidade Através de Anotações

O que é Lombok?

Lombok é uma biblioteca que gera código em tempo de compilação através de anotações. Não impõe semântica específica - é pura redução de boilerplate.

Exemplo com Lombok

@Data
public class Produto {
    private String nome;
    private double preco;

    // Método personalizado
    public void aplicarDesconto(double desconto) {
        this.preco -= desconto;
    }
}

Principais Anotações

@Data: Gera getters, setters, equals(), hashCode(), toString()
@Value: Classe imutável (equivalente a um record)
@Builder: Padrão Builder
@Slf4j: Injeção de logger
@Getter/@Setter: Getters e setters específicos

Comparação Detalhada

Aspecto	Records	Lombok
Semântica	Tipos de produto transparentes	Geração de código
Imutabilidade	Por padrão	Opcional (@Value)
Flexibilidade	Limitada	Alta
Herança	Não suportada	Suportada
Estado Oculto	Proibido	Permitido
Dependência Externa	Não	Sim
Versão Java	14+ (estável no 16+)	Qualquer
Desempenho	Nativo	Geração em tempo de compilação

Quando Usar Records

✅ Use Records para:

1. DTOs (Data Transfer Objects)

public record UsuarioDTO(String nome, String email, LocalDate nascimento) {}

2. Objetos de Valor

public record Dinheiro(BigDecimal valor, String moeda) {}

3. Respostas de API

public record ApiResponse<T>(T dados, int status, String mensagem) {}

4. Configurações Imutáveis

public record DatabaseConfig(String url, String usuario, int timeout) {}

5. Entidades JPA Simples (com limitações)

@Entity
public record Produto(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    Long id,
    String nome,
    BigDecimal preco
) {}

❌ Evite Records quando:

Precisar de mutabilidade
Necessitar de herança
Requerer estado oculto
Trabalhar com frameworks que exigem construtores sem argumentos
Precisar de métodos de ciclo de vida JPA complexos

Quando Usar Lombok

✅ Use Lombok para:

1. Entidades JPA Complexas

@Entity
@Data
@NoArgsConstructor
@AllArgsConstructor
public class Usuario {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String nome;
    private String email;

    @OneToMany(mappedBy = "usuario", cascade = CascadeType.ALL)
    private List<Pedido> pedidos = new ArrayList<>();
}

2. Modelos de Negócio com Comportamento

@Data
@Slf4j
public class ContaBancaria {
    private String numero;
    private BigDecimal saldo;

    public void sacar(BigDecimal valor) {
        log.info("Sacando {} da conta {}", valor, numero);
        if (saldo.compareTo(valor) >= 0) {
            saldo = saldo.subtract(valor);
        } else {
            throw new IllegalArgumentException("Saldo insuficiente");
        }
    }
}

3. Builders Complexos

@Builder
@Data
public class Relatorio {
    private String titulo;
    private LocalDate dataInicio;
    private LocalDate dataFim;
    private List<String> colunas;
    private Map<String, Object> parametros;
}

// Uso
Relatorio relatorio = Relatorio.builder()
    .titulo("Vendas Mensais")
    .dataInicio(LocalDate.now().minusMonths(1))
    .dataFim(LocalDate.now())
    .colunas(Arrays.asList("produto", "quantidade", "valor"))
    .build();

❌ Evite Lombok quando:

O projeto exigir zero dependências externas
Houver problemas de compatibilidade com IDEs
A equipe não estiver familiarizada com a biblioteca
Precisar de garantias semânticas específicas

Casos de Uso Práticos

Cenário 1: Sistema de E-commerce

// DTO para resposta da API - USE RECORD
public record ProdutoResponse(
    Long id,
    String nome,
    BigDecimal preco,
    String categoria
) {}

// Entidade JPA com comportamento - USE LOMBOK
@Entity
@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class Produto {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String nome;
    private BigDecimal preco;
    private String categoria;
    private Integer estoque;

    public void reduzirEstoque(int quantidade) {
        if (estoque < quantidade) {
            throw new IllegalArgumentException("Estoque insuficiente");
        }
        this.estoque -= quantidade;
    }
}

Cenário 2: Sistema Bancário

// Objeto de valor imutável - USE RECORD
public record Moeda(String codigo, String nome, String simbolo) {}

// Entidade complexa com estado mutável - USE LOMBOK
@Entity
@Data
@EqualsAndHashCode(onlyExplicitlyIncluded = true)
@NoArgsConstructor
@Slf4j
public class Conta {
    @Id
    @EqualsAndHashCode.Include
    private String numero;

    private BigDecimal saldo;
    private String titular;

    @OneToMany(mappedBy = "conta", cascade = CascadeType.ALL)
    private List<Transacao> transacoes = new ArrayList<>();

    public void transferir(BigDecimal valor, Conta destino) {
        log.info("Transferindo {} de {} para {}", valor, this.numero, destino.numero);
        // Lógica de transferência
    }
}

Híbrido: Usando Records e Lombok Juntos

// Record com anotações do Lombok para funcionalidades adicionais
@Slf4j
public record ProcessamentoResult(
    String id,
    LocalDateTime timestamp,
    boolean sucesso,
    String mensagem
) {
    public ProcessamentoResult {
        log.info("Resultado do processamento {}: {}", id, sucesso ? "SUCESSO" : "FALHA");
    }
}

O Futuro: Spring Data Commons Recomenda Records

O Spring Framework oficialmente recomenda Records para DTOs e projeções:

// Recomendação oficial do Spring Data
public record NamesOnly(String firstname, String lastname) {}

// Em vez de usar Lombok
@Value
class NamesOnly {
    String firstname, lastname;
}

Diretrizes para Tomada de Decisão

Escolha Records quando:

✅ Estiver no Java 16+
✅ Precisar de objetos imutáveis
✅ Quiser garantias semânticas fortes
✅ Criar DTOs ou objetos de valor
✅ Buscar máxima performance (sem overhead de biblioteca)

Escolha Lombok quando:

✅ Precisar de flexibilidade máxima
✅ Trabalhar com herança
✅ Requerer mutabilidade
✅ Usar versões antigas do Java
✅ Precisar de funcionalidades como @builder ou @Slf4j

Use Ambos quando:

✅ Records para DTOs e objetos de valor
✅ Lombok para entidades e modelos de negócio
✅ Aproveitar o melhor de cada abordagem

Migração Gradual

Estratégia de Migração para Records:

Identifique candidatos: DTOs, objetos de valor, classes imutáveis simples
Migre gradualmente: Comece com classes menos críticas
Teste thoroughly: Verifique serialização e frameworks
Monitore performance: Records podem ter características diferentes

Exemplo de Migração:

// Antes (Lombok)
@Value
public class Endereco {
    String rua;
    String cidade;
    String cep;
}

// Depois (Record)
public record Endereco(String rua, String cidade, String cep) {}

Considerações de Performance

Records:

✅ Sem overhead de biblioteca
✅ Otimizações do compilador
⚠️ Criação de objetos em atualizações (imutabilidade)

Lombok:

✅ Código gerado otimizado
⚠️ Dependência de bibliotecas externas
⚠️ Possível overhead de reflection em algumas situações

Conclusão

A escolha entre Records e Lombok não é uma questão de "melhor" ou "pior", mas sim de adequação ao contexto:

Records brilham quando você precisa de semântica forte, imutabilidade e transparência
Lombok excele quando você precisa de flexibilidade, mutabilidade e compatibilidade com versões antigas

A tendência é usar ambos estrategicamente:

Records para DTOs, objetos de valor e dados imutáveis
Lombok para entidades complexas e modelos de negócio

Com o Java evoluindo e mais projetos adotando versões recentes, Records estão se tornando a escolha padrão para muitos casos de uso. No entanto, Lombok continuará relevante para cenários que demandam máxima flexibilidade.

A chave é entender que essas ferramentas resolvem problemas similares de maneiras diferentes, e a escolha certa depende das necessidades específicas do seu projeto, versão do Java e arquitetura da aplicação.

Referências Bibliográficas

Por que Abandonar @Autowired em Campos e Adotar Injeção via Construtor

Diego de Sousa Brandão — Tue, 15 Jul 2025 00:55:48 +0000

A injeção de dependência via construtor representa uma evolução natural das práticas de desenvolvimento com Spring Framework. Este documento apresenta os fundamentos técnicos que justificam essa transição e como implementá-la efetivamente em projetos modernos.

Contextualização

O Spring Framework oferece três formas principais de injeção de dependência: por campo (field injection), por setter e por construtor. Embora a injeção por campo seja visualmente mais limpa e requeira menos código, ela apresenta limitações significativas que impactam a qualidade, manutenibilidade e robustez das aplicações.

Principais Benefícios da Injeção via Construtor

1. Transparência e Dependências Explícitas

A injeção via construtor expõe claramente todas as dependências de uma classe em sua assinatura. Esta transparência facilita a compreensão do código, permitindo que desenvolvedores identifiquem rapidamente quais componentes uma classe necessita para funcionar corretamente.

Exemplo prático:

// Injeção por campo - dependências ocultas
@Service
public class UserService {
    @Autowired
    private UserRepository userRepository;
    @Autowired
    private EmailService emailService;
    // Dependências não são evidentes na assinatura da classe
}

// Injeção por construtor - dependências explícitas
@Service
public class UserService {
    private final UserRepository userRepository;
    private final EmailService emailService;

    public UserService(UserRepository userRepository, EmailService emailService) {
        this.userRepository = userRepository;
        this.emailService = emailService;
    }
}

2. Testabilidade Aprimorada

A injeção via construtor elimina a dependência do contexto Spring durante os testes unitários. As classes podem ser instanciadas diretamente, com mocks injetados como parâmetros do construtor, resultando em testes mais rápidos e independentes.

Vantagens nos testes:

Eliminação da necessidade de reflection
Testes mais performáticos
Maior simplicidade na configuração de mocks
Independência do framework Spring nos testes unitários

3. Princípio Fail-Fast

A injeção por campo permite a criação de objetos mesmo quando dependências obrigatórias não estão disponíveis, resultando em NullPointerException apenas durante a execução. A injeção via construtor impede a criação do objeto sem suas dependências, tornando problemas visíveis imediatamente durante a inicialização da aplicação.

4. Imutabilidade e Thread Safety

Apenas através da injeção via construtor é possível definir campos de dependência como final. Esta imutabilidade oferece:

Segurança de thread: Campos final são thread-safe por natureza
Prevenção de efeitos colaterais: Impossibilita modificações acidentais das dependências
Clareza conceitual: Facilita o raciocínio sobre o estado dos objetos

5. Detecção Precoce de Dependências Circulares

Ciclos de dependência são detectados imediatamente durante a inicialização dos beans quando se utiliza injeção via construtor. Com injeção por campo, esses problemas podem permanecer ocultos até a execução específica do código afetado.

6. Incentivo ao Bom Design

A injeção via construtor evidencia classes com muitas dependências, naturalmente incentivando a aplicação do Princípio da Responsabilidade Única (SRP). Construtores com muitos parâmetros sinalizam a necessidade de refatoração e decomposição de responsabilidades.

7. Alinhamento com Práticas Modernas do Spring

Desde o Spring 4.3, o framework suporta injeção automática via construtor para classes com construtor único, dispensando a anotação @Autowired. Esta é a abordagem oficialmente recomendada pela equipe do Spring.

Implementação Prática

Padrão Recomendado (Sem Lombok)

@Service
public class OrderService {
    private final OrderRepository orderRepository;
    private final PaymentService paymentService;
    private final NotificationService notificationService;

    public OrderService(OrderRepository orderRepository, 
                       PaymentService paymentService,
                       NotificationService notificationService) {
        this.orderRepository = orderRepository;
        this.paymentService = paymentService;
        this.notificationService = notificationService;
    }

    // métodos da classe...
}

Com Lombok (Quando Apropriado)

@Service
@RequiredArgsConstructor
public class OrderService {
    private final OrderRepository orderRepository;
    private final PaymentService paymentService;
    private final NotificationService notificationService;

    // métodos da classe...
}

Estratégia de Migração

Para Código Legado

Priorização: Inicie por classes críticas e com maior cobertura de testes
Refatoração gradual: Migre uma classe por vez para minimizar riscos
Testes de regressão: Garanta que a funcionalidade permanece inalterada
Validação: Verifique se não há dependências circulares expostas

Para Novos Desenvolvimentos

Adote injeção via construtor como padrão desde o início
Configure linters e ferramentas de análise estática para detectar uso de @Autowired em campos
Estabeleça como prática obrigatória em code reviews

Considerações Especiais

Dependências Opcionais

Para dependências opcionais, utilize @Autowired(required = false) no construtor ou considere padrões como Optional:

public UserService(UserRepository userRepository, 
                   @Autowired(required = false) CacheService cacheService) {
    this.userRepository = userRepository;
    this.cacheService = Optional.ofNullable(cacheService);
}

Performance

A injeção via construtor não apresenta overhead significativo em relação à injeção por campo. Os benefícios em qualidade e manutenibilidade superam amplamente qualquer diferença marginal de performance.

Conclusão

A adoção da injeção via construtor representa um investimento na qualidade de longo prazo do código. Os benefícios em testabilidade, clareza, robustez e alinhamento com as melhores práticas do Spring justificam plenamente essa transição.

Esta mudança não é apenas uma questão de preferência pessoal, mas uma evolução natural em direção a um código mais robusto, testável e maintível, alinhado com os princípios modernos de desenvolvimento de software.

Referências Bibliográficas

Maratona de Testes Automatizados — Step 1: Testes Unitários

Diego de Sousa Brandão — Sun, 08 Jun 2025 16:55:13 +0000

Maratona de Testes em Java: Da Teoria à Prática

Step 1: Testes Unitários - A Base Sólida da Pirâmide de Testes

Índice

Por que testes unitários são fundamentais?
O que realmente define um teste unitário?
O que exatamente devemos testar?
Estruturando seus testes com clareza
As ferramentas do ofício: JUnit e Mockito
Exemplo completo: Testando um Controller REST
Solitary vs. Sociable: Duas abordagens
DRY vs. DAMP nos testes
Evitando armadilhas comuns
Práticas avançadas e técnicas eficazes
Integração Contínua
Lições finais
Conclusão
Recursos recomendados
Referências Bibliográficas

Por que testes unitários são fundamentais?

Testes unitários são como os alicerces de um edifício: invisíveis para o usuário final, mas absolutamente essenciais para a integridade e sustentação de todo o sistema. Eles são a base da "Pirâmide de Testes", um conceito desenvolvido por Mike Cohn que organiza os testes em camadas de diferentes granularidades, indicando também quantos testes devemos ter em cada uma dessas camadas.

No artigo "The Practical Test Pyramid", Ham Vocke destaca que "seus testes unitários serão muito rápidos. Em uma máquina razoável, você poderá rodar milhares deles em poucos minutos." Esta velocidade é crucial para o desenvolvimento ágil, permitindo que você obtenha feedback praticamente instantâneo sobre suas alterações de código.

O que realmente define um teste unitário?

Um teste unitário eficaz possui estas características essenciais:

Característica	Descrição	Por quê isso importa
⚡ Rápido	Executa em milissegundos	Permite feedback imediato durante o desenvolvimento
🧩 Isolado	Sem dependência externa (rede, banco, disco)	Evita falhas por causas externas à unidade testada
🔄 Determinístico	Sempre produz o mesmo resultado	Elimina testes "flaky" (instáveis)
🎯 Focado	Verifica uma única lógica ou comportamento	Facilita identificar exatamente o que falhou
📖 Legível	Clara separação entre cenário e verificação	Permite manutenção e entendimento a longo prazo

Como Ham Vocke menciona, "teste pequenas partes da sua base de código em isolamento e evite acessar bancos de dados, o sistema de arquivos ou fazer requisições HTTP." Este isolamento é o que torna os testes unitários verdadeiramente "unitários".

O que exatamente devemos testar?

Segundo Vocke, "você pode escrever testes unitários para todas as classes do seu código de produção, independentemente da funcionalidade delas." Isso significa que quase tudo pode e deve ser testado unitariamente:

✅ Classes de domínio com regras de negócio
✅ Controllers (testar mapeamentos e respostas)
✅ Services (testar fluxos e orquestrações)
✅ Repositórios com lógica própria
✅ Utils, validators, formatters (funções de propósito específico)

O importante é focar no comportamento observável da unidade, não em sua implementação interna. Como Vocke recomenda, devemos "testar para o comportamento observável em vez de refletir a estrutura interna do código em nossos testes."

Estruturando seus testes com clareza

Ham Vocke destaca duas formas eficazes de estruturar testes, que ele chama de "uma boa estrutura para todos os seus testes":

📐 1. Arrange → Act → Assert

@Test
public void deveCalcularValorTotalComDesconto() {
    // Arrange - Prepara o cenário
    Produto produto = new Produto("Notebook", 2000.0);
    Cliente clienteVip = new Cliente("João", TipoCliente.VIP);

    // Act - Executa a ação
    double valorFinal = calculadoraPreco.calcular(produto, clienteVip);

    // Assert - Verifica o resultado
    assertEquals(1800.0, valorFinal, 0.001);
}

💬 2. Given → When → Then (estilo BDD)

@Test
public void clienteVipDeveReceberDescontoEspecial() {
    // Given - Dado um cliente VIP e um produto
    Cliente clienteVip = new Cliente("Maria", TipoCliente.VIP);
    Produto produto = new Produto("Smartphone", 1000.0);

    // When - Quando calcular o preço final
    double valorFinal = calculadoraPreco.calcular(produto, clienteVip);

    // Then - Então deve aplicar 10% de desconto
    assertEquals(900.0, valorFinal, 0.001);
}

Vocke sugere que este padrão "pode ser aplicado a outros testes de nível mais alto também. Em todos os casos, eles garantem que seus testes permaneçam fáceis e consistentes de ler."

As ferramentas do ofício: JUnit e Mockito

JUnit 5

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import static org.junit.jupiter.api.Assertions.*;

class CalculadoraTest {

    private Calculadora calc;

    @BeforeEach
    void setup() {
        calc = new Calculadora();
    }

    @Test
    @DisplayName("Soma de dois números positivos")
    void deveSomarDoisNumerosPositivos() {
        // Act
        int resultado = calc.somar(5, 3);

        // Assert
        assertEquals(8, resultado);
    }

    @Test
    @DisplayName("Divisão por zero deve lançar exceção")
    void deveLancarExcecaoAoDividirPorZero() {
        // Assert + Act (verificando exceção)
        assertThrows(ArithmeticException.class, () -> {
            calc.dividir(10, 0);
        });
    }
}

Mockito

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.*;

@ExtendWith(MockitoExtension.class)
class PedidoServiceTest {

    @Mock
    DescontoService descontoService;

    @Mock
    EmailService emailService;

    @InjectMocks
    PedidoService pedidoService;

    @Test
    void deveAplicarDescontoAoFinalizarPedido() {
        // Arrange
        Pedido pedido = new Pedido(1L, 100.0);
        when(descontoService.calcularDesconto(pedido)).thenReturn(10.0);

        // Act
        pedidoService.finalizarPedido(pedido);

        // Assert
        assertEquals(90.0, pedido.getValorTotal());
        verify(emailService).enviarConfirmacao(pedido);
    }
}

Exemplo completo: Testando um Controller REST

Vamos ver um exemplo prático de como testar um controller REST em Spring Boot:

O Controller em produção

@RestController
@RequestMapping("/api/produtos")
public class ProdutoController {

    private final ProdutoService produtoService;

    public ProdutoController(ProdutoService produtoService) {
        this.produtoService = produtoService;
    }

    @GetMapping("/{id}")
    public ResponseEntity<ProdutoDTO> buscarPorId(@PathVariable Long id) {
        return produtoService.buscarPorId(id)
                .map(produto -> ResponseEntity.ok(new ProdutoDTO(produto)))
                .orElse(ResponseEntity.notFound().build());
    }

    @PostMapping
    public ResponseEntity<ProdutoDTO> criar(@RequestBody @Valid ProdutoRequest request) {
        Produto produto = produtoService.criar(
            new Produto(request.getNome(), request.getPreco())
        );
        return ResponseEntity
            .created(URI.create("/api/produtos/" + produto.getId()))
            .body(new ProdutoDTO(produto));
    }
}

Teste unitário com MockMVC

Ham Vocke explica que ferramentas como MockMVC são importantes porque "Spring MVC's controller faz uso intensivo de anotações para declarar em quais caminhos eles estão escutando, quais verbos HTTP usar, quais parâmetros eles analisam do caminho da URL ou parâmetros de consulta e assim por diante. Simplesmente invocar um método do controller em seus testes unitários não testará todas essas coisas cruciais."

@ExtendWith(MockitoExtension.class)
class ProdutoControllerTest {

    private MockMvc mockMvc;

    @Mock
    private ProdutoService produtoService;

    @InjectMocks
    private ProdutoController produtoController;

    @BeforeEach
    void setup() {
        mockMvc = MockMvcBuilders
            .standaloneSetup(produtoController)
            .build();
    }

    @Test
    void deveRetornarProdutoQuandoExistir() throws Exception {
        // Arrange
        Produto produto = new Produto("Teclado Mecânico", 350.0);
        produto.setId(1L);

        when(produtoService.buscarPorId(1L))
            .thenReturn(Optional.of(produto));

        // Act & Assert
        mockMvc.perform(get("/api/produtos/1"))
            .andExpect(status().isOk())
            .andExpect(jsonPath("$.nome").value("Teclado Mecânico"))
            .andExpect(jsonPath("$.preco").value(350.0));
    }

    @Test
    void deveRetornarNotFoundQuandoProdutoNaoExistir() throws Exception {
        // Arrange
        when(produtoService.buscarPorId(99L))
            .thenReturn(Optional.empty());

        // Act & Assert
        mockMvc.perform(get("/api/produtos/99"))
            .andExpect(status().isNotFound());
    }

    @Test
    void deveCriarNovoProduto() throws Exception {
        // Arrange
        Produto produtoParaSalvar = new Produto("Mouse", 89.9);
        Produto produtoSalvo = new Produto("Mouse", 89.9);
        produtoSalvo.setId(42L);

        when(produtoService.criar(any(Produto.class)))
            .thenReturn(produtoSalvo);

        // Act & Assert
        mockMvc.perform(post("/api/produtos")
            .contentType(MediaType.APPLICATION_JSON)
            .content("{\"nome\":\"Mouse\",\"preco\":89.9}")
        )
            .andExpect(status().isCreated())
            .andExpect(header().string("Location", "/api/produtos/42"))
            .andExpect(jsonPath("$.nome").value("Mouse"))
            .andExpect(jsonPath("$.preco").value(89.9));
    }
}

Solitary vs. Sociable: Duas abordagens para testes unitários

Segundo Vocke, "alguns argumentam que todos os colaboradores da sua unidade sob teste devem ser substituídos por mocks ou stubs", enquanto "outros argumentam que apenas colaboradores que são lentos ou têm efeitos colaterais maiores deveriam ser substituídos por stubs ou mocks."

Este conceito foi criado por Jay Fields em seu livro "Working Effectively with Unit Tests", que cunhou os termos "testes unitários solitários" para testes que substituem todos os colaboradores, e "testes unitários sociáveis" para testes que permitem interações com colaboradores reais.

Ham Vocke confessa: "Eu me vejo usando ambas as abordagens o tempo todo. Se se torna estranho usar colaboradores reais, usarei mocks e stubs generosamente. Se eu sentir que envolver o colaborador real me dá mais confiança em um teste, apenas faço stub das partes mais externas do meu serviço."

Exemplo de teste solitário (com mocks)

@Test
void deveCalcularImpostoSobreVendaComMocks() {
    // Arrange
    BigDecimal valorBase = new BigDecimal("1000.00");

    // Mockando todas as dependências
    when(aliquotaService.buscarAliquota("SP"))
        .thenReturn(new BigDecimal("0.18"));

    when(descontoService.calcularDesconto(valorBase))
        .thenReturn(new BigDecimal("100.00"));

    // Act
    BigDecimal imposto = calculadoraImpostoService.calcular(valorBase, "SP");

    // Assert
    assertEquals(new BigDecimal("162.00"), imposto); // (1000 - 100) * 0.18
}

Exemplo de teste sociável (com colaboradores reais)

@Test
void deveCalcularImpostoSobreVendaComColaboradoresReais() {
    // Arrange
    BigDecimal valorBase = new BigDecimal("1000.00");

    // Usando implementação real do serviço de desconto
    DescontoService descontoServiceReal = new DescontoServiceImpl();

    // Ainda mockando o serviço de alíquota (externo)
    AliquotaService aliquotaMock = mock(AliquotaService.class);
    when(aliquotaMock.buscarAliquota("SP"))
        .thenReturn(new BigDecimal("0.18"));

    // Injetando uma mistura de dependências reais e mockadas
    CalculadoraImpostoService calculadora = 
        new CalculadoraImpostoServiceImpl(descontoServiceReal, aliquotaMock);

    // Act
    BigDecimal imposto = calculadora.calcular(valorBase, "SP");

    // Assert
    assertEquals(new BigDecimal("180.00"), imposto); // Considerando que o desconto real é 0
}

DRY vs. DAMP nos testes: Equilibrando clareza e repetição

Ham Vocke alerta: "Não tente ser excessivamente DRY (Don't Repeat Yourself). Duplicação é aceitável se melhorar a legibilidade."

Em testes, muitas vezes é melhor priorizar a clareza em vez da não-repetição. Um acrônimo útil para recordar é DAMP: Descriptive And Meaningful Phrases.

Exemplo questionável (muito DRY):

// Definição central, reusada em todos os testes
private Cliente clienteVip;
private Produto produtoPadrao;

@BeforeEach
void setup() {
    clienteVip = new Cliente("João", TipoCliente.VIP);
    produtoPadrao = new Produto("Item", 100.0);
}

@Test
void deveAplicarDescontoVipEmProduto() {
    assertEquals(90.0, calculadoraPreco.calcular(produtoPadrao, clienteVip));
}

@Test
void deveIncluirFreteGratisPara() {
    assertTrue(beneficioService.temFreteGratis(clienteVip, produtoPadrao));
}

Exemplo melhor (mais DAMP):

@Test
void deveAplicarDescontoVipEmProduto() {
    // Arrange - Dados específicos para este teste
    Cliente clienteVip = new Cliente("João", TipoCliente.VIP);
    Produto notebook = new Produto("Notebook", 2000.0);

    // Act
    double valorComDesconto = calculadoraPreco.calcular(notebook, clienteVip);

    // Assert - Expectativa clara
    assertEquals(1800.0, valorComDesconto, 
                "Cliente VIP deve receber 10% de desconto");
}

@Test
void deveIncluirFreteGratisPara() {
    // Arrange - Dados específicos para este teste
    Cliente clienteVip = new Cliente("Maria", TipoCliente.VIP);
    Produto smartTV = new Produto("Smart TV", 1500.0);

    // Act
    boolean temFreteGratis = beneficioService.temFreteGratis(clienteVip, smartTV);

    // Assert - Expectativa clara
    assertTrue(temFreteGratis, 
              "Cliente VIP deve ter frete grátis independente do produto");
}

Evitando armadilhas comuns

"Mas eu preciso testar este método privado!"

Ham Vocke alerta: "Se você já se encontrou em uma situação em que realmente precisa testar um método privado, você deve dar um passo atrás e se perguntar por quê." Ele continua: "Estou bastante certo de que isso é mais um problema de design do que um problema de escopo."

Quando você sente essa necessidade, geralmente há um problema de design da classe — ela provavelmente está fazendo muitas coisas e violando o princípio da responsabilidade única.

A solução mais elegante:

// Antes: Classe grande com método privado complexo
public class FaturamentoService {
    public BigDecimal calcular(Pedido pedido) {
        // lógica...
        return calcularImpostos(valorBase); // método privado complexo
    }

    private BigDecimal calcularImpostos(BigDecimal valor) {
        // lógica complexa de cálculo de impostos
    }
}

// Depois: Extrair para uma classe dedicada com interface pública
public class FaturamentoService {
    private final ImpostoCalculator impostoCalculator;

    public FaturamentoService(ImpostoCalculator impostoCalculator) {
        this.impostoCalculator = impostoCalculator;
    }

    public BigDecimal calcular(Pedido pedido) {
        // lógica...
        return impostoCalculator.calcular(valorBase); // Agora é público!
    }
}

public class ImpostoCalculator {
    public BigDecimal calcular(BigDecimal valor) {
        // mesma lógica complexa, agora testável
    }
}

"Preciso ter 100% de cobertura!"

Vocke argumenta contra testar código trivial: "Sim, você deve testar a interface pública. Mais importante, no entanto, você não testa código trivial. Não se preocupe, Kent Beck disse que tudo bem. Você não ganhará nada testando getters ou setters simples ou outras implementações triviais."

Focar em cobertura por si só pode levar a testes ruins que não adicionam valor. Busque qualidade em vez de quantidade.

Práticas avançadas e técnicas eficazes

À medida que você ganha experiência em testes unitários, algumas técnicas avançadas podem ajudar a tornar seus testes mais elegantes, legíveis e fáceis de manter. Vejamos três técnicas importantes que podem elevar significativamente a qualidade da sua suite de testes.

1. Dados de teste expressivos

O que é: Métodos de fábrica (factory methods) ou objetos builders que criam dados de teste com nomes semânticos, em vez de usar configurações inline de objetos diretamente nos testes.

Quando usar:

Quando os objetos de teste têm muitas propriedades que precisam ser configuradas
Quando você repete a mesma configuração de objetos em vários testes
Quando a configuração obscurece a intenção principal do teste

Benefícios:

Foco no "o quê" está sendo testado, não no "como" os objetos são criados
Leitura mais natural - o nome do método descreve o cenário
Encapsulamento de detalhes irrelevantes para a intenção do teste
Fácil reutilização entre testes similares

// Ruim: Dados aleatórios desconexos
@Test
void deveAprovarCreditoParaClienteBomPagador() {
    Cliente cliente = new Cliente("X123", 35);
    cliente.setScoreCredito(750);
    cliente.setRendaMensal(5000.0);

    boolean aprovado = creditoService.analisarCredito(cliente, 10000.0);

    assertTrue(aprovado);
}

// Melhor: Nome do método de fábrica expressivo
@Test
void deveAprovarCreditoParaClienteBomPagador() {
    Cliente clienteBomPagador = criarClienteComBomHistoricoCredito();

    boolean aprovado = creditoService.analisarCredito(clienteBomPagador, 10000.0);

    assertTrue(aprovado);
}

private Cliente criarClienteComBomHistoricoCredito() {
    Cliente cliente = new Cliente("Maria", 35);
    cliente.setScoreCredito(750);
    cliente.setRendaMensal(5000.0);
    return cliente;
}

Você também pode evoluir para padrões mais sofisticados como builders fluentes:

// Usando um builder expressivo
@Test
void deveAprovarCreditoParaClienteBomPagador() {
    Cliente clienteBomPagador = ClienteBuilder.padrao()
        .comBomHistoricoCredito()
        .comRendaAdequada()
        .build();

    boolean aprovado = creditoService.analisarCredito(clienteBomPagador, 10000.0);

    assertTrue(aprovado);
}

2. Assertion libraries expressivas

O que são: Bibliotecas que oferecem uma sintaxe mais fluente e legível para verificações, substituindo os métodos padrão do JUnit.

Quando usar:

Para verificações complexas ou múltiplas em um único objeto
Quando se deseja uma leitura mais próxima da linguagem natural
Para verificações de coleções, onde se quer verificar múltiplos aspectos

Bibliotecas populares:

AssertJ: fluente e orientada a objetos
Hamcrest: baseada em matchers
Truth (Google): alternativa simples e expressiva

Benefícios:

Testes mais legíveis, quase como frases em inglês
Mensagens de erro mais descritivas quando falham
Encadeamento de verificações reduz duplicação
Maior expressividade para casos complexos

// JUnit padrão - Funcionais mas menos expressivas
assertEquals(3, lista.size());
assertTrue(lista.contains("item1"));
assertTrue(cliente.isAtivo());

// AssertJ - Mais fluente e expressivo
assertThat(lista)
    .hasSize(3)
    .contains("item1")
    .doesNotContain("item99");

assertThat(cliente.isAtivo()).isTrue();

Quando um teste falha, a mensagem de erro com AssertJ é mais informativa:

Expected size:<3> but was:<2>
Expected to contain:<"item1"> but did not

3. Testes parametrizados para casos similares

O que são: Testes que executam o mesmo código com diferentes entradas e expectativas de saída, gerando automaticamente múltiplos casos de teste a partir de uma única definição.

Quando usar:

Para testar múltiplas variações de um mesmo caso (comportamento com diferentes entradas)
Para regras de negócio que têm muitos casos específicos (ex: cálculos tributários)
Quando a lógica é a mesma, mas os dados variam
Para evitar duplicação de código em testes semelhantes

Benefícios:

Redução drástica de código duplicado
Facilidade para adicionar novos casos de teste
Documentação clara de todos os casos suportados
Facilita identificar quais casos específicos falharam

@ParameterizedTest
@CsvSource({
    "SP, 0.18",
    "RJ, 0.20",
    "MG, 0.17",
    "RS, 0.17"
})
void deveCalcularImpostoCorretoPorEstado(String estado, BigDecimal aliquotaEsperada) {
    // Arrange
    Produto produto = new Produto("Genérico", 100.0);

    // Act
    BigDecimal aliquota = impostoService.obterAliquota(estado, produto);

    // Assert
    assertEquals(aliquotaEsperada, aliquota);
}

O JUnit 5 suporta múltiplas fontes de dados para testes parametrizados:

@ValueSource: para listas simples de valores (@ValueSource(ints = {1, 2, 3}))
@CsvSource: para pares ou tuplas de valores como mostrado acima
@EnumSource: para testar com valores de um enum
@MethodSource: para casos complexos onde os dados são gerados por um método
@ArgumentsSource: para implementações personalizadas de geradores de dados

Essas técnicas avançadas são particularmente úteis quando sua base de código cresce e você precisa manter um conjunto grande de testes. Elas ajudam a reduzir a duplicação, melhorar a legibilidade e facilitar a manutenção a longo prazo.

Integração Contínua: Executando testes unitários automaticamente

Os testes unitários devem ser executados:

Localmente antes de commit/push
Na CI em cada push para qualquer branch
Antes de merge para branches principais

Este feedback rápido é possível graças à velocidade dos testes unitários.

Lições finais

Ham Vocke resume bem: "Uma vez que você pegar o jeito de escrever testes unitários, você se tornará cada vez mais fluente em escrevê-los. Substitua colaboradores externos por stubs, configure alguns dados de entrada, chame seu assunto sob teste e verifique se o valor retornado é o que você esperava."

Testes unitários são um investimento que:

⏱️ Economiza tempo a longo prazo
🔒 Permite refatorações com segurança
📚 Documenta o comportamento esperado
💻 Melhora o design do código
🧠 Reduz a carga cognitiva ao desenvolver

Conclusão

Como resumido no artigo de referência: "O código de teste é tão importante quanto o código de produção. Dê a ele o mesmo nível de cuidado e atenção. 'Isso é apenas código de teste' não é uma desculpa válida para justificar código desleixado."

Ao dominar a arte dos testes unitários, você estabelece a base sólida para construir um sistema robusto e confiável, que pode evoluir com segurança ao longo do tempo.

No próximo passo da nossa maratona, abordaremos testes de integração - a camada intermediária da pirâmide de testes que verifica como seus componentes trabalham juntos.

Recursos recomendados

📕 "Working Effectively with Unit Tests" por Jay Fields
📗 "Test Driven Development: By Example" por Kent Beck
📘 "Clean Code" por Robert C. Martin (capítulo sobre testes)
🌐 Documentação oficial do JUnit 5
🌐 Documentação oficial do Mockito
🌐 Documentação oficial do AssertJ

Referências Bibliográficas

Vocke, Ham. (2018). "The Practical Test Pyramid". Martin Fowler. Disponível em: https://martinfowler.com/articles/practical-test-pyramid.html
Cohn, Mike. (2009). "Succeeding with Agile: Software Development Using Scrum". Addison-Wesley Professional.
Fields, Jay. (2014). "Working Effectively with Unit Tests". Leanpub.
Beck, Kent. (2002). "Test Driven Development: By Example". Addison-Wesley Professional.
Martin, Robert C. (2008). "Clean Code: A Handbook of Agile Software Craftsmanship". Prentice Hall.
Fowler, Martin. (2006). "Mocks Aren't Stubs". MartinFowler.com. Disponível em: https://martinfowler.com/articles/mocksArentStubs.html
Spring Framework Documentation. "Testing". Disponível em: https://docs.spring.io/spring-framework/docs/current/reference/html/testing.html
JUnit 5 User Guide. Disponível em: https://junit.org/junit5/docs/current/user-guide/
Mockito Reference Documentation. Disponível em: https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html
AssertJ Documentation. Disponível em: https://assertj.github.io/doc/

Maratona de Testes Automatizados — Step 0: Fundamentos, Importância e a Pirâmide de Testes

Diego de Sousa Brandão — Tue, 06 May 2025 02:55:38 +0000

Step 0: Fundamentos, Importância e a Pirâmide de Testes

Índice

Por que testamos software?
Entendendo a Pirâmide de Testes
O Anti-padrão: O Sorvete de Testes
Duplicação Inteligente vs. Duplicação Desnecessária
DRY vs. DAMP em Testes
Testes de Caixa Branca vs. Caixa Preta
Princípios Essenciais para Todos os Níveis
O que vem a seguir?
Referências Bibliográficas

Por que testamos software?

Testar software transcende a simples busca por defeitos — é fundamentalmente um ato de construir confiança. Testes automatizados proporcionam a liberdade de evoluir o código sem receio, realizar refatorações profundas, validar integrações complexas, e entregar continuamente com a segurança de um sistema verificado.

Como Ham Vocke observa no artigo "The Practical Test Pyramid":

"Automating your repetitive tests can be a big game changer in your life as a software developer. Automate these tests and you no longer have to mindlessly follow click protocols in order to check if your software still works correctly. Automate your tests and you can change your codebase without batting an eye."

Tradução:

"Automatizar seus testes repetitivos pode ser um grande divisor de águas na sua vida como desenvolvedor de software. Automatize esses testes e você não precisará mais seguir protocolos de cliques sem pensar para verificar se seu software ainda funciona corretamente. Automatize seus testes e você poderá mudar sua base de código sem piscar."

A automação de testes é transformadora precisamente porque liberta desenvolvedores de tarefas repetitivas e tediosas, convertendo-as em verificações automáticas:

Testes manuais → Repetitivos → Tediosos → Propensos a erros → Lentos
Testes automatizados → Consistentes → Confiáveis → Rápidos → Confortantes

O impacto disso vai além da qualidade do software; reflete diretamente na qualidade de vida do desenvolvedor e na dinâmica das equipes.

Entendendo a Pirâmide de Testes

A Pirâmide de Testes (Test Pyramid) foi introduzida por Mike Cohn em seu livro Succeeding with Agile. Trata-se de uma metáfora visual poderosa que orienta a construção de uma suíte de testes balanceada, rápida e sustentável a longo prazo.

A pirâmide nos comunica dois conceitos fundamentais:

Diferentes níveis de granularidade: Os testes são agrupados em categorias que variam de escopo, desde pequenos métodos isolados até o sistema completo integrado.
Distribuição ideal: Quanto mais subimos na pirâmide, menor deve ser a quantidade de testes, seguindo o princípio de "muitos testes rápidos e baratos na base, poucos testes caros e lentos no topo".

Como Ham Vocke explica:

"Write lots of small and fast unit tests. Write some more coarse-grained tests and very few high-level tests that test your application from end to end."

Tradução:

"Escreva muitos testes unitários pequenos e rápidos. Escreva alguns testes mais abrangentes e muito poucos testes de alto nível que testem sua aplicação de ponta a ponta."

A estrutura contemporânea da pirâmide consiste em:

Nível	Tipo de Teste	Características	Quantidade
Base	Testes Unitários	Rápidos, isolados, confiáveis	Muitos
Meio	Testes de Integração	Verificam comunicação entre componentes	Moderada
Topo	Testes E2E/UI	Simulam comportamento do usuário	Poucos

Esta distribuição não é acidental — reflete o equilíbrio econômico entre velocidade de feedback, cobertura de cenários e custo de manutenção.

Nota sobre a Evolução da Pirâmide de Testes

Nota: Esta seção complementa o entendimento sobre a Pirâmide de Testes, explicando sua evolução histórica.

É importante destacar que a Pirâmide de Testes que apresentamos neste artigo representa uma versão mais contemporânea e refinada do conceito original introduzido por Mike Cohn.

A Pirâmide Original de Cohn (2009) consistia em três camadas:

Base: Testes Unitários (Unit Tests)
Meio: Testes de Serviço (Service Tests)
Topo: Testes de Interface do Usuário (UI Tests)

O termo "Service Tests" usado por Cohn era um tanto ambíguo e causou confusão na comunidade de desenvolvimento. Ele se referia a testes que verificavam a funcionalidade sem passar pela interface do usuário, mas que podiam envolver múltiplos componentes ou módulos.

A Pirâmide Moderna que apresentamos evoluiu para oferecer maior clareza e se adaptar às práticas atuais de desenvolvimento:

Base: Testes Unitários (Unit Tests)
Meio: Testes de Integração (Integration Tests)
Topo: Testes E2E/UI (End-to-End/UI Tests)

Por que a mudança?

Esta evolução não foi apenas uma questão de terminologia, mas reflete mudanças fundamentais nas práticas de desenvolvimento:

Maior granularidade: A camada intermediária agora é geralmente subdividida para acomodar diferentes tipos de integrações (API, componentes, contratos).
Arquiteturas distribuídas: Com a popularização de microsserviços e sistemas distribuídos, o conceito de "Service Tests" se tornou insuficiente para capturar a complexidade das integrações modernas.
DevOps e CI/CD: A automação completa de pipelines de entrega contínua demandou uma categorização mais precisa dos testes para otimizar velocidade e eficiência.
Práticas ágeis maduras: A experiência acumulada nas últimas décadas permitiu refinar o modelo para melhor servir aos fluxos de trabalho modernos.

Martin Fowler e outros influentes profissionais da área contribuíram para esta evolução, resultando em uma pirâmide mais detalhada e adaptada às necessidades contemporâneas de desenvolvimento de software.

A essência da metáfora original de Cohn permanece intacta: muitos testes rápidos na base, poucos testes lentos no topo. O refinamento da pirâmide representa nossa compreensão mais sofisticada de como implementar este princípio em contextos diversos e complexos.

O Anti-padrão: O Sorvete de Testes

Enquanto a pirâmide aponta para a estabilidade e eficiência, seu anti-padrão é o "Sorvete de Testes" (Test Ice Cream Cone), termo cunhado por Alberto Savoia e popularizado por Martin Fowler.

No sorvete de testes, a distribuição é invertida:

A base (testes unitários) é pequena ou inexistente
O meio (integração) é moderado
O topo (UI/E2E) é excessivamente volumoso

Ham Vocke alerta:

"Watch out that you don't end up with a test ice-cream cone that will be a nightmare to maintain and takes way too long to run."

Tradução:

"Tenha cuidado para não acabar com um sorvete de testes que será um pesadelo para manter e demorará muito tempo para executar."

As consequências desta distorção são severas:

Feedback lento: O ciclo de desenvolvimento se torna arrastado
Diagnóstico difícil: Falhas são complexas de isolar e corrigir
Fragilidade: Pequenas mudanças causam falhas em cascata
Alto custo: A manutenção consome recursos desproporcionais

A regra prática é: quanto mais alto o teste na pirâmide, maior o custo de manutenção, tempo de execução e propensão a falhas intermitentes ("flaky tests").

Duplicação Inteligente vs. Duplicação Desnecessária

Um equívoco comum é assumir que qualquer forma de duplicação de cobertura de testes é inaceitável. Ham Vocke apresenta uma visão mais equilibrada sobre este tema:

"If a higher-level test gives you more confidence that your application works correctly, you should have it. Writing a unit test for a Controller class helps to test the logic within the Controller itself. Still, this won't tell you whether the REST endpoint this Controller provides actually responds to HTTP requests."

Tradução:

"Se um teste de nível superior lhe dá mais confiança de que sua aplicação funciona corretamente, você deve tê-lo. Escrever um teste unitário para uma classe Controller ajuda a testar a lógica dentro do Controller em si. Ainda assim, isso não dirá se o endpoint REST que este Controller fornece realmente responde a requisições HTTP."

Existem dois tipos de duplicação em testes:

Duplicação inteligente: Testa o mesmo comportamento, mas sob perspectivas diferentes e complementares:

Teste unitário: valida a lógica interna
Teste de integração: valida a comunicação entre componentes
Teste E2E: valida o fluxo completo sob a perspectiva do usuário

Duplicação desnecessária: Testa exatamente o mesmo aspecto em múltiplos níveis, sem valor agregado:

Repetir todos os casos de borda e condicionais em todos os níveis da pirâmide
Duplicar testes de validação em múltiplas camadas

Ham Vocke recomenda:

"If you have tested all conditions confidently on a lower-level test, there's no need to keep a higher-level test in your test suite."

Tradução:

"Se você testou todas as condições com confiança em um teste de nível inferior, não há necessidade de manter um teste de nível superior em sua suíte de testes."

Isto nos leva a duas regras práticas:

Se um teste de nível superior encontra um erro e não há teste de nível inferior falhando, você precisa escrever um teste de nível inferior
Priorize a implementação de testes nos níveis mais baixos da pirâmide, sempre que possível.

DRY vs. DAMP em Testes

DRY (Don't Repeat Yourself) é um princípio fundamental da engenharia de software, mas em testes, existe uma tensão com outro princípio: DAMP (Descriptive And Meaningful Phrases).

Ham Vocke observa:

"Don't try to be overly DRY. Duplication is okay, if it improves readability. Try to find a balance between DRY and DAMP code."

Tradução:

"Não tente ser excessivamente DRY. Duplicação é aceitável, se melhorar a legibilidade. Tente encontrar um equilíbrio entre código DRY e DAMP."

Esta visão reflete uma maturidade na abordagem dos testes automatizados:

Princípio	Foco	Benefício	Riscos se usado em excesso
DRY	Evitar redundância	Facilidade de manutenção	Testes interdependentes e frágeis
DAMP	Clareza e intenção	Testes auto-documentados	Admite certa repetição, desde que contribua para a clareza

Em testes, clareza é frequentemente mais valiosa que concisão extrema, pois testes são lidos não apenas por quem os escreveu, mas por desenvolvedores investigando falhas ou entendendo o comportamento esperado do sistema.

Testes de Caixa Branca vs. Caixa Preta

Para compreender melhor os diferentes níveis da pirâmide, é útil relacioná-los com dois paradigmas clássicos de teste:

Testes de Caixa Branca (White Box):

Utilizam conhecimento da estrutura interna do código
Testam caminhos de execução, cobertura de branches, lógica interna
Focam em "como" o sistema implementa comportamentos
Predominantes em: testes unitários e testes de integração

Testes de Caixa Preta (Black Box):

Tratam o sistema como uma "caixa fechada"
Testam apenas as interfaces públicas e o comportamento observável
Focam em "o que" o sistema faz, não em como faz
Predominantes em: testes E2E e testes de aceitação

Existe também uma abordagem híbrida:

Testes de Caixa Cinza (Grey Box):

Combinam conhecimento da estrutura interna com teste via interfaces externas
Usam conhecimento do design para testar de forma mais eficiente
Comuns em: testes de integração e testes de API

Nível da Pirâmide	Tipo	Abordagem Predominante
Base	Unitários	Caixa Branca
Meio	Integração/Contratos	Caixa Cinza
Topo	UI, E2E, Aceitação	Caixa Preta

Princípios Essenciais para Todos os Níveis

Independentemente do nível da pirâmide, alguns princípios fundamentais devem ser observados:

Teste comportamento, não implementação:
- Foque no "o quê", não no "como"
- Isso permite refatoração sem quebrar testes

"Test for observable behavior instead." - Ham Vocke

Tradução:

"Teste o comportamento observável, em vez disso." - Ham Vocke

Código de teste é código de produção:
- Aplique as mesmas práticas de qualidade
- Refatore e mantenha limpo

"Test code is as important as production code. Give it the same level of care and attention." - Ham Vocke

Tradução:

"O código de teste é tão importante quanto o código de produção. Dê a ele o mesmo nível de cuidado e atenção." - Ham Vocke

Estruture claramente:
- Use padrão "Arrange-Act-Assert" ou "Given-When-Then"
- Mantenha o teste focado em um único aspecto

"A good structure for all your tests is this one: Set up the test data, Call your method under test, Assert that the expected results are returned." - Ham Vocke

Tradução:

"Uma boa estrutura para todos os seus testes é esta: Configure os dados de teste, Chame seu método sob teste, Verifique que os resultados esperados são retornados." - Ham Vocke

Priorize feedback rápido:
- Coloque testes rápidos nos primeiros estágios do pipeline
- Testes lentos em estágios posteriores

"A good build pipeline tells you that you messed up as quick as possible." - Ham Vocke

Tradução:

"Um bom pipeline de build informa que você errou o mais rápido possível." - Ham Vocke

Evite duplicação desnecessária:
- Se já está bem testado em nível mais baixo, um teste mais alto deve focar em novos aspectos
- Seja implacável eliminando testes que não agregam valor

"I delete high-level tests that are already covered on a lower level (given they don't provide extra value)." - Ham Vocke

Tradução:

"Eu excluo testes de alto nível que já estão cobertos em um nível inferior (desde que não forneçam valor adicional)." - Ham Vocke

O que vem a seguir?

No Step 1 da nossa maratona, mergulharemos a fundo na base da pirâmide: os testes unitários. Exploraremos:

A definição precisa de uma "unidade" de teste
A diferença entre testes "sociáveis" e "solitários"
O uso eficaz de Mocks e Stubs
A estruturação ideal de testes unitários
Exemplos práticos em Java utilizando JUnit e Mockito

Prepare-se para construir uma base sólida que permitirá que seu código evolua com segurança e confiança!

Referências Bibliográficas

Vocke, Ham. (2018). "The Practical Test Pyramid". Martin Fowler. Disponível em: https://martinfowler.com/articles/practical-test-pyramid.html
Cohn, Mike. (2009). "Succeeding with Agile: Software Development Using Scrum". Addison-Wesley Professional.
Fowler, Martin. (2012). "Test Pyramid". MartinFowler.com. Disponível em: https://martinfowler.com/bliki/TestPyramid.html
Freeman, Steve; Pryce, Nat. (2009). "Growing Object-Oriented Software, Guided by Tests". Addison-Wesley Professional.
Meszaros, Gerard. (2007). "xUnit Test Patterns: Refactoring Test Code". Addison-Wesley Professional.
Khorikov, Vladimir. (2020). "Unit Testing: Principles, Practices, and Patterns". Manning Publications.
Osherove, Roy. (2013). "The Art of Unit Testing: With Examples in .NET". Manning Publications.
Beck, Kent. (2002). "Test Driven Development: By Example". Addison-Wesley Professional.
Fields, Jay. (2014). "Working Effectively with Unit Tests". Leanpub.
Savoia, Alberto. (2011). "The Way of Testivus". Disponível em: https://www.artima.com/weblogs/viewpost.jsp?thread=203994

A Arte da Simplicidade no Desenvolvimento de Software: DRY, KISS, YAGNI e TDA

Diego de Sousa Brandão — Wed, 30 Apr 2025 22:59:33 +0000

"A simplicidade é o último grau de sofisticação." - Leonardo da Vinci

Índice

Introdução
O que são Princípios de Desenvolvimento de Software?
Por que seguir Princípios de Desenvolvimento é importante?
DRY - Don't Repeat Yourself (Não Se Repita)
DRY e o Padrão Factory
KISS - Keep It Simple, Stupid (Mantenha Simples, Estúpido)
YAGNI - You Aren't Gonna Need It (Você Não Vai Precisar Disso)
TDA - Tell, Don't Ask (Diga, Não Pergunte)
TDA e a Lei de Demeter
Críticas e Limitações dos Princípios
Integrando os Princípios em seu Desenvolvimento
Conclusão
Referências Bibliográficas

Introdução

No cenário atual do desenvolvimento de software, onde a complexidade dos sistemas cresce exponencialmente, a busca por clareza e simplicidade tornou-se uma necessidade fundamental. Desenvolvedores experientes reconhecem que código complicado não é sinônimo de código sofisticado - pelo contrário, a verdadeira elegância reside na simplicidade.

Este artigo explora quatro princípios fundamentais que transformaram o desenvolvimento de software: DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid), YAGNI (You Aren't Gonna Need It) e TDA (Tell, Don't Ask). Estes princípios não são apenas técnicas isoladas, mas filosofias de design que, quando aplicadas corretamente, resultam em código mais limpo, manutenível e, paradoxalmente, mais poderoso.

O que são Princípios de Desenvolvimento de Software?

Princípios de desenvolvimento de software são diretrizes conceituais que orientam as decisões de design e implementação durante o processo de criação de software. Diferentemente de padrões de design específicos ou frameworks, estes princípios transcendem linguagens de programação e paradigmas, servindo como uma bússola para navegação no vasto campo de possibilidades do desenvolvimento de software.

Estes princípios representam o conhecimento acumulado ao longo de décadas pela comunidade global de desenvolvimento, capturando lições frequentemente aprendidas da maneira mais difícil: através de projetos malsucedidos, manutenções onerosas e bugs persistentes.

Por que seguir Princípios de Desenvolvimento é importante?

A importância de seguir princípios de desenvolvimento transcende preferências estéticas de código. Considere as seguintes vantagens:

Redução de custos a longo prazo: Sistemas bem projetados são consideravelmente mais econômicos para manter e estender.
Escalabilidade: Código que segue princípios sólidos adapta-se melhor ao crescimento da aplicação.
Facilidade de colaboração: Princípios compartilhados estabelecem uma linguagem comum entre desenvolvedores.
Resiliência: Sistemas bem projetados respondem melhor a mudanças nas especificações.
Qualidade perceptível: Usuários finais identificam indiretamente a qualidade do design através da confiabilidade e responsividade do sistema.

Examinemos agora os quatro princípios que são o foco deste artigo, explorando sua origem, aplicação e impacto.

DRY - Don't Repeat Yourself (Não Se Repita)

Origem e História

O princípio DRY foi formulado por Andy Hunt e Dave Thomas em seu influente livro "The Pragmatic Programmer", publicado em 1999. A definição original é direta e poderosa: "Todo conhecimento deve ter uma representação única, inequívoca e autoritativa dentro de um sistema."

Embora Hunt e Thomas tenham cunhado o termo, o conceito de evitar repetição em código já era uma prática valorizada anteriormente. O mérito deles foi articular e formalizar este conhecimento tácito que já circulava entre desenvolvedores experientes.

Por que é importante?

A importância do DRY reside em sua capacidade de reduzir significativamente a dívida técnica. Quando o mesmo código ou lógica é repetido em múltiplos lugares, qualquer alteração necessária deve ser implementada em todos esses locais. Inevitavelmente, alguns desses pontos serão esquecidos, resultando em inconsistências e bugs difíceis de rastrear.

Além disso, o DRY:

Reduz o tamanho do código, facilitando sua compreensão
Concentra a lógica em locais específicos, facilitando otimizações
Melhora a coesão do código, agrupando funcionalidades relacionadas
Minimiza a ocorrência de erros durante atualizações e manutenções

Exemplos Práticos em Java

Sem aplicar o princípio DRY:

@Service
public class ProdutoService {

    private final ProdutoRepository produtoRepository;

    public ProdutoService(ProdutoRepository produtoRepository) {
        this.produtoRepository = produtoRepository;        
    }

    public ProdutoResponseDTO buscarProdutoPorId(Long id) {
        Produto produto = produtoRepository.findById(id)
            .orElseThrow(() -> new RecursoNaoEncontradoException("Produto não encontrado"));

        ProdutoResponseDTO responseDTO = new ProdutoResponseDTO();
        responseDTO.setId(produto.getId());
        responseDTO.setNome(produto.getNome());
        responseDTO.setDescricao(produto.getDescricao());
        responseDTO.setPreco(produto.getPreco());
        responseDTO.setCategoria(produto.getCategoria());
        responseDTO.setDisponivel(produto.isDisponivel());
        return responseDTO;
    }

    public List<ProdutoResponseDTO> buscarTodosProdutos() {
        List<Produto> produtos = produtoRepository.findAll();

        List<ProdutoResponseDTO> responseDTOs = new ArrayList<>();
        for (Produto produto : produtos) {
            ProdutoResponseDTO responseDTO = new ProdutoResponseDTO();
            responseDTO.setId(produto.getId());
            responseDTO.setNome(produto.getNome());
            responseDTO.setDescricao(produto.getDescricao());
            responseDTO.setPreco(produto.getPreco());
            responseDTO.setCategoria(produto.getCategoria());
            responseDTO.setDisponivel(produto.isDisponivel());
            responseDTOs.add(responseDTO);
        }

        return responseDTOs;
    }

    public List<ProdutoResponseDTO> buscarProdutosPorCategoria(String categoria) {
        List<Produto> produtos = produtoRepository.findByCategoria(categoria);

        List<ProdutoResponseDTO> responseDTOs = new ArrayList<>();
        for (Produto produto : produtos) {
            ProdutoResponseDTO responseDTO = new ProdutoResponseDTO();
            responseDTO.setId(produto.getId());
            responseDTO.setNome(produto.getNome());
            responseDTO.setDescricao(produto.getDescricao());
            responseDTO.setPreco(produto.getPreco());
            responseDTO.setCategoria(produto.getCategoria());
            responseDTO.setDisponivel(produto.isDisponivel());
            responseDTOs.add(responseDTO);
        }

        return responseDTOs;
    }
}

Aplicando o princípio DRY:

@Service
public class ProdutoService {

    private final ProdutoRepository produtoRepository;

    public ProdutoService(ProdutoRepository produtoRepository) {
        this.produtoRepository = produtoRepository;        
    }

    public ProdutoResponseDTO buscarProdutoPorId(Long id) {
        Produto produto = produtoRepository.findById(id)
            .orElseThrow(() -> new RecursoNaoEncontradoException("Produto não encontrado"));

        return converterParaDTO(produto);
    }

    public List<ProdutoResponseDTO> buscarTodosProdutos() {
        List<Produto> produtos = produtoRepository.findAll();
        return produtos.stream()
                .map(this::converterParaDTO)
                .collect(Collectors.toList());
    }

    public List<ProdutoResponseDTO> buscarProdutosPorCategoria(String categoria) {
        List<Produto> produtos = produtoRepository.findByCategoria(categoria);
        return produtos.stream()
                .map(this::converterParaDTO)
                .collect(Collectors.toList());
    }

    private ProdutoResponseDTO converterParaDTO(Produto produto) {
        ProdutoResponseDTO responseDTO = new ProdutoResponseDTO();
        responseDTO.setId(produto.getId());
        responseDTO.setNome(produto.getNome());
        responseDTO.setDescricao(produto.getDescricao());
        responseDTO.setPreco(produto.getPreco());
        responseDTO.setCategoria(produto.getCategoria());
        responseDTO.setDisponivel(produto.isDisponivel());
        return responseDTO;
    }
}

Na versão DRY, extraímos a lógica de conversão da entidade para DTO em um método separado converterParaDTO(), que é reutilizado em todos os métodos que precisam dessa funcionalidade. Se a estrutura do DTO mudar ou se novos campos forem adicionados, precisamos alterar apenas esse método, não todos os lugares onde a conversão é feita.

Aplicando o princípio DRY com MapStruct:

Uma maneira ainda mais elegante de aplicar o princípio DRY para mapeamento entre objetos é utilizando a biblioteca MapStruct. Esta abordagem elimina completamente a necessidade de escrever código de mapeamento manual, reduzindo ainda mais a duplicação e o potencial para erros:

// 1. Definir a interface do mapper
@Mapper(componentModel = "spring")
public interface ProdutoMapper {

    ProdutoResponseDTO toDTO(Produto produto);

    List<ProdutoResponseDTO> toDTOList(List<Produto> produtos);
}

// 2. Refatorar o serviço para usar o mapper
@Service
public class ProdutoService {

    private final ProdutoRepository produtoRepository;
    private final ProdutoMapper produtoMapper;

    public ProdutoService(ProdutoRepository produtoRepository, ProdutoMapper produtoMapper) {
        this.produtoRepository = produtoRepository;
        this.produtoMapper = produtoMapper;
    }

    public ProdutoResponseDTO buscarProdutoPorId(Long id) {
        Produto produto = produtoRepository.findById(id)
            .orElseThrow(() -> new RecursoNaoEncontradoException("Produto não encontrado"));

        return produtoMapper.toDTO(produto);
    }

    public List<ProdutoResponseDTO> buscarTodosProdutos() {
        List<Produto> produtos = produtoRepository.findAll();
        return produtoMapper.toDTOList(produtos);
    }

    public List<ProdutoResponseDTO> buscarProdutosPorCategoria(String categoria) {
        List<Produto> produtos = produtoRepository.findByCategoria(categoria);
        return produtoMapper.toDTOList(produtos);
    }
}

O MapStruct gera automaticamente a implementação da interface ProdutoMapper durante o processo de compilação, eliminando toda a duplicação de código de mapeamento. Se a estrutura do DTO ou da entidade mudar, basta atualizar a interface do mapper e a implementação será regenerada automaticamente.

Esta abordagem oferece várias vantagens sobre o mapeamento manual:

Elimina completamente o código repetitivo: Não precisamos escrever nenhum código de mapeamento.
Alta performance: O código gerado pelo MapStruct é muito eficiente, similar ao que escreveríamos manualmente.
Menos propensão a erros: Se novos campos forem adicionados à entidade ou ao DTO, o compilador gerará avisos se o mapeamento não estiver completo.
Configurações avançadas: MapStruct oferece suporte a mapeamentos complexos, conversões personalizadas e herança.

Este é um exemplo perfeito da aplicação do princípio DRY levado ao seu máximo potencial, onde eliminamos não apenas a duplicação direta, mas também a necessidade de escrever código repetitivo em primeiro lugar.

DRY e o Padrão Factory

É importante destacar a relação sinérgica entre o princípio DRY e o padrão de design Factory. O padrão Factory é um dos padrões de criação mais utilizados na programação orientada a objetos e apresenta particular afinidade com o princípio DRY.

Quando aplicamos DRY para eliminar duplicação de código relacionado à criação de objetos complexos, frequentemente implementamos alguma variação do padrão Factory. Observe o exemplo com um cenário típico de API REST:

Sem Factory (violando DRY):

@RestController
@RequestMapping("/api/v1/pedidos")
public class PedidoController {

    private final PedidoService pedidoService;

    public PedidoController(PedidoService pedidoService) {
        this.pedidoService = pedidoService;        
    }

    @PostMapping
    public ResponseEntity<PedidoDTO> criarPedido(@RequestBody PedidoRequest request) {

        // Criação do cliente manualmente
        Cliente cliente = new Cliente();
        cliente.setId(request.getClienteId());
        cliente.setTipoCliente(TipoCliente.valueOf(request.getTipoCliente()));

        if (TipoCliente.PREMIUM.equals(cliente.getTipoCliente())) {
            cliente.setLimiteCredito(10000.0);
            cliente.setBeneficioFrete(true);
            cliente.setPrazoEntregaDias(2);
        } else if (TipoCliente.REGULAR.equals(cliente.getTipoCliente())) {
            cliente.setLimiteCredito(5000.0);
            cliente.setBeneficioFrete(false);
            cliente.setPrazoEntregaDias(5);
        } else { // NOVO
            cliente.setLimiteCredito(1000.0);
            cliente.setBeneficioFrete(false);
            cliente.setPrazoEntregaDias(7);
        }

        Pedido pedido = pedidoService.criarPedido(request, cliente);
        return ResponseEntity.ok(convertToDTO(pedido));
    }
}

@RestController
@RequestMapping("/api/v1/clientes")
public class ClienteController {

    private final ClienteService clienteService;

    public ClienteController (ClienteService clienteService) {
        this.clienteService = clienteService;        
    }

    @PostMapping
    public ResponseEntity<ClienteDTO> cadastrarCliente(@RequestBody ClienteRequest request) {

        // Criação do cliente manualmente (duplicação de código)
        Cliente cliente = new Cliente();
        cliente.setNome(request.getNome());
        cliente.setEmail(request.getEmail());
        cliente.setTipoCliente(TipoCliente.valueOf(request.getTipoCliente()));

        if (TipoCliente.PREMIUM.equals(cliente.getTipoCliente())) {
            cliente.setLimiteCredito(10000.0);
            cliente.setBeneficioFrete(true);
            cliente.setPrazoEntregaDias(2);
        } else if (TipoCliente.REGULAR.equals(cliente.getTipoCliente())) {
            cliente.setLimiteCredito(5000.0);
            cliente.setBeneficioFrete(false);
            cliente.setPrazoEntregaDias(5);
        } else { // NOVO
            cliente.setLimiteCredito(1000.0);
            cliente.setBeneficioFrete(false);
            cliente.setPrazoEntregaDias(7);
        }

        Cliente clienteSalvo = clienteService.salvarCliente(cliente);
        return ResponseEntity.ok(convertToDTO(clienteSalvo));
    }
}

Com Factory (aplicando DRY):

// Factory para criação de clientes
@Component
public class ClienteFactory {

    public Cliente criarCliente(Long id, String tipoClienteStr) {
        Cliente cliente = new Cliente();
        cliente.setId(id);

        TipoCliente tipoCliente = TipoCliente.valueOf(tipoClienteStr);
        cliente.setTipoCliente(tipoCliente);

        // Configuração baseada no tipo de cliente
  /*       
   * Estou utilizando neste exemplo o switch case do Java 21,
   * que introduz a sintaxe moderna com "->", mais legível e concisa.
 */
        switch (tipoCliente) {
            case PREMIUM -> configurarClientePremium(cliente);
            case REGULAR -> configurarClienteRegular(cliente);
            case NOVO    -> configurarClienteNovo(cliente);
       }

      return cliente;
    }

    public Cliente criarCliente(ClienteRequest request) {
        Cliente cliente = new Cliente();
        cliente.setNome(request.getNome());
        cliente.setEmail(request.getEmail());

        TipoCliente tipoCliente = TipoCliente.valueOf(request.getTipoCliente());
        cliente.setTipoCliente(tipoCliente);

        // Configuração baseada no tipo de cliente
        switch (tipoCliente) {
            case PREMIUM -> configurarClientePremium(cliente);
            case REGULAR -> configurarClienteRegular(cliente);
            case NOVO    -> configurarClienteNovo(cliente);
        }

        return cliente;
    }

    private void configurarClientePremium(Cliente cliente) {
        cliente.setLimiteCredito(10000.0);
        cliente.setBeneficioFrete(true);
        cliente.setPrazoEntregaDias(2);
    }

    private void configurarClienteRegular(Cliente cliente) {
        cliente.setLimiteCredito(5000.0);
        cliente.setBeneficioFrete(false);
        cliente.setPrazoEntregaDias(5);
    }

    private void configurarClienteNovo(Cliente cliente) {
        cliente.setLimiteCredito(1000.0);
        cliente.setBeneficioFrete(false);
        cliente.setPrazoEntregaDias(7);
    }
}

// Usando a Factory nos controllers
@RestController
@RequestMapping("/api/v1/pedidos")
public class PedidoController {

    private final PedidoService pedidoService;   
    private final ClienteFactory clienteFactory;

    public PedidoController(PedidoService pedidoService, 
                            ClienteFactory clienteFactory) {
        this.pedidoService = pedidoService;
        this.clienteFactory = clienteFactory;
    }

    @PostMapping
    public ResponseEntity<PedidoDTO> criarPedido(@RequestBody PedidoRequest request) {


        // Criação do cliente através da factory
        Cliente cliente = clienteFactory.criarCliente(
            request.getClienteId(), 
            request.getTipoCliente()
        );

        Pedido pedido = pedidoService.criarPedido(request, cliente);
        return ResponseEntity.ok(convertToDTO(pedido));
    }
}

@RestController
@RequestMapping("/api/v1/clientes")
public class ClienteController {

    private final ClienteService clienteService;    
    private final ClienteFactory clienteFactory;

    public ClienteController (ClienteService  clienteService, 
                              ClienteFactory clienteFactory) {
        this.clienteService = clienteService;
        this.clienteFactory = clienteFactory;
    }

    @PostMapping
    public ResponseEntity<ClienteDTO> cadastrarCliente(@RequestBody ClienteRequest request) {


        // Criação do cliente através da factory
        Cliente cliente = clienteFactory.criarCliente(request);

        Cliente clienteSalvo = clienteService.salvarCliente(cliente);
        return ResponseEntity.ok(convertToDTO(clienteSalvo));
    }
}

Este padrão não apenas elimina a duplicação, mas também centraliza a lógica de criação e configuração de clientes, facilitando futuras modificações e manutenção. Se as regras de negócio para um tipo específico de cliente mudarem, apenas os métodos relevantes na factory precisarão ser atualizados, em vez de buscar e alterar essa lógica em múltiplos controllers e serviços.

KISS - Keep It Simple, Stupid (Mantenha Simples, Estúpido)

Origem e História

O princípio KISS tem uma origem interessante no campo da engenharia aeroespacial. Foi atribuído a Kelly Johnson, engenheiro da Lockheed Skunk Works, responsável pelo design de aeronaves como o U-2 e o SR-71 Blackbird durante as décadas de 1960 e 1970. Johnson instruía seus engenheiros que seus sistemas deveriam ser simples o suficiente para serem reparados por um mecânico comum em condições de campo com ferramentas básicas.

O acrônimo "Keep It Simple, Stupid" foi posteriormente adotado pela Marinha dos EUA em 1960. O conceito rapidamente transcendeu o contexto militar e encontrou aplicação em diversas áreas, incluindo o desenvolvimento de software.

Por que é importante?

A importância do KISS no desenvolvimento de software é multifacetada:

Manutenibilidade: Código simples é mais fácil de entender e modificar.
Depuração: Soluções simples apresentam menor superfície para bugs potenciais.
Integração de novos desenvolvedores: Profissionais recém-chegados ao projeto conseguem compreender e contribuir para o código mais rapidamente.
Desempenho: Soluções simples frequentemente apresentam melhor desempenho que alternativas complexas.
Adaptabilidade: Sistemas simples geralmente respondem melhor a novos requisitos.

Exemplos Práticos em Java

Sem aplicar o princípio KISS:

@Service
public class ValidadorEmailService {    

    private final UsuarioRepository usuarioRepository;    
    private final EmailBlacklistRepository blacklistRepository;    
    private final ConfiguracoesService configuracoesService;

    public ValidadorEmailService(
            UsuarioRepository usuarioRepository,
            EmailBlacklistRepository blacklistRepository,
            ConfiguracoesService configuracoesService) {
        this.usuarioRepository = usuarioRepository;
        this.blacklistRepository = blacklistRepository;
        this.configuracoesService = configuracoesService;
    }

    public ValidationResult validarEmail(String email) {
        ValidationResult result = new ValidationResult();

        // Verificação 1: Email não pode ser nulo ou vazio
        if (email == null || email.trim().isEmpty()) {
            result.addError("EMAIL_EMPTY", "Email não pode ser vazio");
            return result;
        }

        // Verificação 2: Formato básico do email
        if (!email.contains("@")) {
            result.addError("EMAIL_INVALID_FORMAT", "Email deve conter @");
            return result;
        }

        // Verificação 3: Validação estrutural detalhada
        String[] partes = email.split("@");
        if (partes.length != 2) {
            result.addError("EMAIL_INVALID_STRUCTURE", "Email deve ter exatamente uma parte local e uma parte de domínio");
            return result;
        }

        String localPart = partes[0];
        String domainPart = partes[1];

        if (localPart.isEmpty()) {
            result.addError("EMAIL_LOCAL_PART_EMPTY", "Parte local do email não pode ser vazia");
            return result;
        }

        if (domainPart.isEmpty()) {
            result.addError("EMAIL_DOMAIN_EMPTY", "Domínio do email não pode ser vazio");
            return result;
        }

        if (!domainPart.contains(".")) {
            result.addError("EMAIL_INVALID_DOMAIN", "Domínio deve ter pelo menos um ponto");
            return result;
        }

        String[] domainParts = domainPart.split("\\.");
        for (String part : domainParts) {
            if (part.isEmpty()) {
                result.addError("EMAIL_INVALID_DOMAIN_PART", "Partes do domínio não podem ser vazias");
                return result;
            }
        }

        // Verificação 4: Verificação de caracteres permitidos
        String allowedCharsLocal = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789.-_+";
        for (char c : localPart.toCharArray()) {
            if (allowedCharsLocal.indexOf(c) < 0) {
                result.addError("EMAIL_INVALID_CHAR_LOCAL", "Caractere não permitido na parte local: " + c);
                return result;
            }
        }

        String allowedCharsDomain = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789.-";
        for (char c : domainPart.toCharArray()) {
            if (allowedCharsDomain.indexOf(c) < 0) {
                result.addError("EMAIL_INVALID_CHAR_DOMAIN", "Caractere não permitido no domínio: " + c);
                return result;
            }
        }

        // Verificação 5: Regras de negócio específicas
        if (blacklistRepository.isEmailDomainBlacklisted(domainPart)) {
            result.addError("EMAIL_DOMAIN_BLACKLISTED", "Domínio não permitido");
            return result;
        }

        if (usuarioRepository.existsByEmail(email) && configuracoesService.isEmailUniqueRequired()) {
            result.addError("EMAIL_ALREADY_EXISTS", "Email já cadastrado");
            return result;
        }

        // Se chegou até aqui, o email é válido
        result.setValid(true);
        return result;
    }
}

Aplicando o princípio KISS:

@Service
public class ValidadorEmailService {

    private final UsuarioRepository usuarioRepository;
    private final EmailBlacklistRepository blacklistRepository;   
    private final ConfiguracoesService configuracoesService;

    public ValidadorEmailService(UsuarioRepository usuarioRepository,
            EmailBlacklistRepository blacklistRepository,
            ConfiguracoesService configuracoesService) {
        this.usuarioRepository = usuarioRepository;
        this.blacklistRepository = blacklistRepository;
        this.configuracoesService = configuracoesService;
    }

    // Expressão regular para validação de email seguindo RFC 5322
    private static final Pattern EMAIL_PATTERN = 
        Pattern.compile("^[a-zA-Z0-9_+&*-]+(?:\\.[a-zA-Z0-9_+&*-]+)*@(?:[a-zA-Z0-9-]+\\.)+[a-zA-Z]{2,7}$");

    public ValidationResult validarEmail(String email) {
        ValidationResult result = new ValidationResult();

        // Verificação 1: Email não pode ser nulo ou vazio
        if (email == null || email.trim().isEmpty()) {
            result.addError("EMAIL_EMPTY", "Email não pode ser vazio");
            return result;
        }

        // Verificação 2: Formato do email usando regex
        if (!EMAIL_PATTERN.matcher(email).matches()) {
            result.addError("EMAIL_INVALID_FORMAT", "Formato de email inválido");
            return result;
        }

        // Verificação 3: Regras de negócio específicas
        String dominio = email.substring(email.lastIndexOf('@') + 1);

        if (blacklistRepository.isEmailDomainBlacklisted(dominio)) {
            result.addError("EMAIL_DOMAIN_BLACKLISTED", "Domínio não permitido");
            return result;
        }

        if (usuarioRepository.existsByEmail(email) && configuracoesService.isEmailUniqueRequired()) {
            result.addError("EMAIL_ALREADY_EXISTS", "Email já cadastrado");
            return result;
        }

        // Se chegou até aqui, o email é válido
        result.setValid(true);
        return result;
    }
}

Na versão KISS, utilizamos uma expressão regular padronizada para validar o formato do email, em vez de implementar manualmente todas as verificações estruturais. Isso torna o código significativamente mais curto, mais legível e menos propenso a erros, enquanto mantém todas as regras de negócio necessárias.

Aplicando o princípio KISS com expressão regular e Apache Commons Lang3:

import org.apache.commons.lang3.StringUtils;

@Service
public class ValidadorEmailService {

    private static final Pattern EMAIL_PATTERN = 
        Pattern.compile("^[a-zA-Z0-9_+&*-]+(?:\\.[a-zA-Z0-9_+&*-]+)*@(?:[a-zA-Z0-9-]+\\.)+[a-zA-Z]{2,7}$");

    public ValidationResult validarEmail(String email) {
        ValidationResult result = new ValidationResult();

        // Utilização do StringUtils.isBlank() da Apache Commons Lang3
        if (StringUtils.isBlank(email)) {
            result.addError("EMAIL_EMPTY", "Email não pode ser vazio");
            return result;
        }

        // Validação de formato com regex
        if (!EMAIL_PATTERN.matcher(email).matches()) {
            result.addError("EMAIL_INVALID_FORMAT", "Formato de email inválido");
            return result;
        }

        // Demais regras de negócio...

        result.setValid(true);
        return result;
    }
}

Por que isso é KISS?

Ao usar o método StringUtils.isBlank() da biblioteca Apache Commons Lang3, encapsulamos a verificação de null, string vazia e espaços em branco em uma única chamada clara e descritiva. Isso reduz ruído, melhora a legibilidade e evita erros comuns em validações manuais.

Essa abordagem exemplifica bem o princípio KISS — evitar reinventar a roda e utilizar ferramentas confiáveis para manter o código simples, expressivo e eficiente.

YAGNI - You Aren't Gonna Need It (Você Não Vai Precisar Disso)

Origem e História

O princípio YAGNI surgiu no contexto do Extreme Programming (XP), uma metodologia ágil de desenvolvimento de software formulada por Kent Beck no final dos anos 1990. O conceito central propõe que os desenvolvedores não devem adicionar funcionalidades até que sejam realmente necessárias, não apenas porque potencialmente poderiam ser úteis no futuro.

YAGNI é um princípio contra-intuitivo para muitos desenvolvedores, pois contraria o instinto natural de planejar com antecedência e tentar antecipar necessidades futuras. No entanto, a experiência coletiva da indústria demonstrou que a maioria das funcionalidades projetadas para uso futuro nunca são efetivamente necessárias, ou são implementadas de forma diferente quando a necessidade real emerge.

Por que é importante?

A importância do YAGNI pode ser compreendida através de seus benefícios diretos:

Foco em valor imediato: Direciona os recursos para resolver problemas reais e atuais.
Redução de complexidade: Cada funcionalidade adicional aumenta a complexidade do sistema.
Economia de recursos: Tempo e energia são conservados ao evitar desenvolvimento desnecessário.
Design mais claro: Sistemas projetados para resolver problemas reais tendem a apresentar designs mais coerentes.
Adaptabilidade: É mais fácil adaptar um sistema simples a novos requisitos do que retrabalhar um sistema complexo.

Exemplos Práticos em Java

Sem aplicar o princípio YAGNI:

@Entity
@Table(name = "usuarios")
public class Usuario {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    private String nome;

    @Column(nullable = false, unique = true)
    private String email;

    @Column(nullable = false)
    private String senha;

    // Campos necessários atualmente
    private boolean ativo;
    private LocalDateTime dataCriacao;
    private LocalDateTime ultimoLogin;

    // Campos para funcionalidades futuras que "talvez" sejam necessárias
    private String telefone;
    private String endereco;
    private String complemento;
    private String cidade;
    private String estado;
    private String cep;
    private LocalDate dataNascimento;
    private String genero;
    private String fotoPerfil;
    private String biografia;
    private String tokenResetSenha;
    private LocalDateTime dataExpiracaoToken;
    private boolean contaVerificada;
    private String tokenVerificacao;
    private Integer tentativasLogin;
    private boolean bloqueado;
    private LocalDateTime dataBloqueio;
    private String preferenciasNotificacao;
    private String configuracaoPrivacidade;
    private String tipoUsuario;
    private Float avaliacao;
    private Integer numeroAvaliacoes;

    // Relações que "podem ser úteis" no futuro
    @OneToMany(mappedBy = "usuario")
    private List<Pedido> pedidos;

    @OneToMany(mappedBy = "usuario")
    private List<Endereco> enderecos;

    @ManyToMany
    @JoinTable(
        name = "usuarios_interesses",
        joinColumns = @JoinColumn(name = "usuario_id"),
        inverseJoinColumns = @JoinColumn(name = "interesse_id")
    )
    private Set<Interesse> interesses;

    @ManyToMany
    @JoinTable(
        name = "usuarios_roles",
        joinColumns = @JoinColumn(name = "usuario_id"),
        inverseJoinColumns = @JoinColumn(name = "role_id")
    )
    private Set<Role> roles;

    // Getters e setters para TODOS os campos...
    // (métodos omitidos para brevidade)
}

@RestController
@RequestMapping("/api/v1/usuarios")
public class UsuarioController {

    private final UsuarioService usuarioService;

    public UsuarioController(UsuarioService usuarioService) {
        this.usuarioService = usuarioService;
    }

    @GetMapping("/{id}")
    public ResponseEntity<UsuarioDTO> buscarUsuario(@PathVariable Long id) {
        Usuario usuario = usuarioService.buscarPorId(id);
        UsuarioDTO dto = converterParaDTO(usuario);
        return ResponseEntity.ok(dto);
    }

    private UsuarioDTO converterParaDTO(Usuario usuario) {
        // Conversão com todos os campos possíveis
        UsuarioDTO dto = new UsuarioDTO();
        dto.setId(usuario.getId());
        dto.setNome(usuario.getNome());
        dto.setEmail(usuario.getEmail());
        dto.setAtivo(usuario.isAtivo());
        dto.setDataCriacao(usuario.getDataCriacao());
        dto.setUltimoLogin(usuario.getUltimoLogin());

        // Campos para funcionalidades futuras
        dto.setTelefone(usuario.getTelefone());
        dto.setEndereco(usuario.getEndereco());
        dto.setComplemento(usuario.getComplemento());
        dto.setCidade(usuario.getCidade());
        dto.setEstado(usuario.getEstado());
        dto.setCep(usuario.getCep());
        dto.setDataNascimento(usuario.getDataNascimento());
        dto.setGenero(usuario.getGenero());
        dto.setFotoPerfil(usuario.getFotoPerfil());
        dto.setBiografia(usuario.getBiografia());
        dto.setContaVerificada(usuario.isContaVerificada());
        dto.setBloqueado(usuario.isBloqueado());
        dto.setTipoUsuario(usuario.getTipoUsuario());
        dto.setAvaliacao(usuario.getAvaliacao());
        dto.setNumeroAvaliacoes(usuario.getNumeroAvaliacoes());

        // Relações
        if (usuario.getPedidos() != null) {
            dto.setPedidos(usuario.getPedidos().stream()
                .map(this::converterPedidoParaDTO)
                .collect(Collectors.toList()));
        }

        if (usuario.getEnderecos() != null) {
            dto.setEnderecos(usuario.getEnderecos().stream()
                .map(this::converterEnderecoParaDTO)
                .collect(Collectors.toList()));
        }

        return dto;
    }


}

Aplicando o princípio YAGNI:

@Entity
@Table(name = "usuarios")
public class Usuario {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    private String nome;

    @Column(nullable = false, unique = true)
    private String email;

    @Column(nullable = false)
    private String senha;

    // Apenas campos necessários para os requisitos atuais
    private boolean ativo;
    private LocalDateTime dataCriacao;
    private LocalDateTime ultimoLogin;

    // Getters e setters apenas para os campos existentes
    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getNome() {
        return nome;
    }

    public void setNome(String nome) {
        this.nome = nome;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }

    public String getSenha() {
        return senha;
    }

    public void setSenha(String senha) {
        this.senha = senha;
    }

    public boolean isAtivo() {
        return ativo;
    }

    public void setAtivo(boolean ativo) {
        this.ativo = ativo;
    }

    public LocalDateTime getDataCriacao() {
        return dataCriacao;
    }

    public void setDataCriacao(LocalDateTime dataCriacao) {
        this.dataCriacao = dataCriacao;
    }

    public LocalDateTime getUltimoLogin() {
        return ultimoLogin;
    }

    public void setUltimoLogin(LocalDateTime ultimoLogin) {
        this.ultimoLogin = ultimoLogin;
    }
}

@RestController
@RequestMapping("/api/v1/usuarios")
public class UsuarioController {

    private final UsuarioService usuarioService;

    public UsuarioController(UsuarioService usuarioService) {
        this.usuarioService = usuarioService;
    }

    @GetMapping("/{id}")
    public ResponseEntity<UsuarioDTO> buscarUsuario(@PathVariable Long id) {
        Usuario usuario = usuarioService.buscarPorId(id);
        UsuarioDTO dto = converterParaDTO(usuario);
        return ResponseEntity.ok(dto);
    }

    private UsuarioDTO converterParaDTO(Usuario usuario) {
        // Apenas os campos necessários atualmente
        UsuarioDTO dto = new UsuarioDTO();
        dto.setId(usuario.getId());
        dto.setNome(usuario.getNome());
        dto.setEmail(usuario.getEmail());
        dto.setAtivo(usuario.isAtivo());
        dto.setDataCriacao(usuario.getDataCriacao());
        dto.setUltimoLogin(usuario.getUltimoLogin());
        return dto;
    }

    // Apenas os métodos CRUD necessários...
}

Na versão YAGNI, a entidade Usuario e seu respectivo DTO contêm apenas os campos necessários para os requisitos atuais do sistema. Campos adicionais, relacionamentos e métodos que poderiam ser úteis no futuro foram eliminados. Isso resulta em um código mais limpo, mais fácil de entender e manter. Se futuramente houver necessidade de adicionar novos campos ou relacionamentos, eles podem ser incluídos quando a necessidade real surgir, evitando a complexidade desnecessária e o esforço de manutenção de código que pode nunca ser utilizado.

TDA - Tell, Don't Ask (Diga, Não Pergunte)

Origem e História

O princípio "Tell, Don't Ask" foi popularizado por Andy Hunt e Dave Thomas (os mesmos autores de "The Pragmatic Programmer" que formalizaram o DRY). O conceito fundamental estabelece que objetos devem ser responsáveis por seu próprio comportamento, e o código cliente deve "dizer" a um objeto o que fazer, em vez de "perguntar" sobre seu estado interno e tomar decisões baseadas nessa informação.

Este princípio é fundamentalmente relacionado à programação orientada a objetos e enfatiza o encapsulamento - o princípio de que os detalhes internos de um objeto devem ser ocultos do mundo exterior.

Por que é importante?

A importância do TDA manifesta-se em vários aspectos:

Encapsulamento: Mantém a lógica relacionada a dados específicos junto com esses dados.
Coesão: Resulta em classes mais coesas onde comportamentos relacionados estão agrupados.
Desacoplamento: Reduz o acoplamento entre componentes do sistema.
Manutenibilidade: Mudanças em regras de negócio afetam apenas as classes responsáveis por essas regras.
Testabilidade: Classes que seguem TDA são geralmente mais fáceis de testar isoladamente.

Exemplos Práticos em Java

Sem aplicar o princípio TDA:

@Service
public class PedidoService {

    private final PedidoRepository pedidoRepository;        
    private final ClienteRepository clienteRepository;    
    private final ProdutoRepository produtoRepository;    
    private final EmailService emailService;

    public PedidoService(PedidoRepository pedidoRepository, 
                        ClienteRepository clienteRepository,
                        ProdutoRepository produtoRepository,
                        EmailService emailService) {
        this.pedidoRepository = pedidoRepository;
        this.clienteRepository = clienteRepository;
        this.produtoRepository = produtoRepository;
        this.emailService = emailService;
    }

    public void processarPagamento(Long pedidoId, String formaPagamento) {
        Pedido pedido = pedidoRepository.findById(pedidoId)
            .orElseThrow(() -> new RecursoNaoEncontradoException("Pedido não encontrado"));

        Cliente cliente = pedido.getCliente();

        // Valida disponibilidade dos produtos
        for (ItemPedido item : pedido.getItens()) {
            Produto produto = item.getProduto();

            // Verifica se tem estoque suficiente
            if (produto.getEstoqueDisponivel() < item.getQuantidade()) {
                throw new NegocioException("Produto " + produto.getNome() + " sem estoque suficiente");
            }
        }

        // Verifica limite do cliente para pagamento por crédito
        if ("CREDITO".equals(formaPagamento)) {
            BigDecimal limiteDisponivel = cliente.getLimiteCredito().subtract(cliente.getSaldoUtilizado());

            if (pedido.getValorTotal().compareTo(limiteDisponivel) > 0) {
                throw new NegocioException("Cliente não possui limite de crédito suficiente");
            }

            // Atualiza saldo utilizado do cliente
            cliente.setSaldoUtilizado(cliente.getSaldoUtilizado().add(pedido.getValorTotal()));
            clienteRepository.save(cliente);
        }

        // Atualiza status do pedido e processa pagamento
        pedido.setStatus(StatusPedido.PAGO);
        pedido.setFormaPagamento(formaPagamento);
        pedido.setDataPagamento(LocalDateTime.now());

        // Reduz estoque dos produtos
        for (ItemPedido item : pedido.getItens()) {
            Produto produto = item.getProduto();
            produto.setEstoqueDisponivel(produto.getEstoqueDisponivel() - item.getQuantidade());
            produtoRepository.save(produto);
        }

        pedidoRepository.save(pedido);

        // Envia email de confirmação
// Utilizando Text Block (Java 15+) para melhor legibilidade da mensagem
String mensagem = """
    Seu pedido #%d no valor de R$ %.2f foi confirmado com sucesso.
    """.formatted(pedido.getId(), pedido.getValorTotal());

emailService.enviarEmail(cliente.getEmail(), "Confirmação de Pagamento", mensagem);

    }
}

Aplicando o princípio TDA:

@Service
public class PedidoService {

    private final PedidoRepository pedidoRepository;    
    private final EmailService emailService;

    public PedidoService(PedidoRepository pedidoRepository,
                         EmailService emailService){
    this.pedidoRepository = pedidoRepository;
    this.emailService = emailService;
    }

    public void processarPagamento(Long pedidoId, String formaPagamento) {
        Pedido pedido = pedidoRepository.findById(pedidoId)
            .orElseThrow(() -> new RecursoNaoEncontradoException("Pedido não encontrado"));

        // Validar disponibilidade de produtos
        pedido.validarDisponibilidadeProdutos();

        // Processar pagamento
        boolean pagamentoRealizado = pedido.processarPagamento(formaPagamento);

        if (!pagamentoRealizado) {
            throw new NegocioException("Falha ao processar pagamento");
        }

        pedidoRepository.save(pedido);

        // Enviar confirmação ao cliente
        pedido.enviarConfirmacao(emailService);
    }
}

@Entity
public class Pedido {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne
    private Cliente cliente;

    @OneToMany(cascade = CascadeType.ALL, mappedBy = "pedido")
    private List<ItemPedido> itens;

    @Enumerated(EnumType.STRING)
    private StatusPedido status;

    private String formaPagamento;
    private LocalDateTime dataPagamento;
    private BigDecimal valorTotal;

    // Outros campos e getters/setters

    public void validarDisponibilidadeProdutos() {
        for (ItemPedido item : itens) {
            if (!item.validarDisponibilidade()) {
                throw new NegocioException("Produto " + item.getProduto().getNome() + " sem estoque suficiente");
            }
        }
    }

    public boolean processarPagamento(String formaPagamento) {
        // Validar pagamento com base na forma escolhida
        if ("CREDITO".equals(formaPagamento)) {
            boolean temLimite = cliente.validarLimiteCredito(valorTotal);
            if (!temLimite) {
                return false;
            }
            cliente.utilizarCredito(valorTotal);
        }

        // Atualizar status e data
        this.status = StatusPedido.PAGO;
        this.formaPagamento = formaPagamento;
        this.dataPagamento = LocalDateTime.now();

        // Atualizar estoque
        itens.forEach(ItemPedido::atualizarEstoque);

        return true;
    }

    public void enviarConfirmacao(EmailService emailService) {
    // Utilizando Text Block (Java 15+) para melhor legibilidade da mensagem
    String mensagem = """
        Seu pedido #%d no valor de R$ %.2f foi confirmado com sucesso.
        """.formatted(id, valorTotal);

    emailService.enviarEmail(cliente.getEmail(), "Confirmação de Pagamento", mensagem);
}

    }
}

@Entity
public class Cliente {
    // Campos e outros métodos

    private BigDecimal limiteCredito;
    private BigDecimal saldoUtilizado;

    public boolean validarLimiteCredito(BigDecimal valorCompra) {
        BigDecimal limiteDisponivel = limiteCredito.subtract(saldoUtilizado);
        return valorCompra.compareTo(limiteDisponivel) <= 0;
    }

    public void utilizarCredito(BigDecimal valor) {
        this.saldoUtilizado = saldoUtilizado.add(valor);
    }
}

@Entity
public class ItemPedido {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne
    private Pedido pedido;

    @ManyToOne
    private Produto produto;

    private Integer quantidade;
    private BigDecimal valorUnitario;

    // Getters e setters

    public boolean validarDisponibilidade() {
        return produto.getEstoqueDisponivel() >= quantidade;
    }

    public void atualizarEstoque() {
        produto.reduzirEstoque(quantidade);
    }
}

@Entity
public class Produto {
    // Campos e getters/setters

    private Integer estoqueDisponivel;

    public void reduzirEstoque(int quantidade) {
        if (estoqueDisponivel < quantidade) {
            throw new NegocioException("Estoque insuficiente");
        }
        this.estoqueDisponivel -= quantidade;
    }
}

Na versão que aplica o princípio TDA, cada entidade é responsável por seu próprio comportamento. O PedidoService não pergunta mais sobre o estado interno dos objetos para tomar decisões; em vez disso, delega comportamentos aos objetos apropriados. Por exemplo:

O Pedido é responsável por validar a disponibilidade de seus itens.
O Cliente é responsável por validar seu próprio limite de crédito.
Cada ItemPedido sabe como validar sua disponibilidade e atualizar o estoque.
O Produto é responsável por gerenciar seu próprio estoque.

Este design encapsula melhor o comportamento dentro dos objetos relevantes, tornando o código mais modular, mais fácil de manter e estender. Além disso, facilita a adição de novas regras de negócio relacionadas a cada entidade sem precisar modificar o serviço principal.

TDA e a Lei de Demeter

É relevante observar que o princípio Tell, Don't Ask (TDA) frequentemente opera em conjunto com a Lei de Demeter (LoD), também conhecida como "princípio do menor conhecimento". A Lei de Demeter estabelece que um objeto só deve invocar métodos que pertençam a:

O próprio objeto
Objetos recebidos como parâmetros para o método
Objetos criados diretamente pelo método
Propriedades/campos diretos do objeto

No exemplo do TDA previamente discutido, quando transformamos o código, estamos também aderindo à Lei de Demeter. Vamos analisar um exemplo mais específico:

Código violando a Lei de Demeter:

@Service
public class RelatorioVendasService {

    private final VendaRepository vendaRepository;

    public RelatorioVendasService(VendaRepository vendaRepository) {
        this.vendaRepository = vendaRepository;
    }

    public RelatorioMensal gerarRelatorioMensal(Long lojaId, int mes, int ano) {
        List<Venda> vendas = vendaRepository.findByLojaIdAndPeriodo(lojaId, mes, ano);

        RelatorioMensal relatorio = new RelatorioMensal(lojaId, mes, ano);

        for (Venda venda : vendas) {
            // Viola Lei de Demeter: navega pela cadeia de objetos
            String nomeProduto = venda.getItens().get(0).getProduto().getNome();
            String categoriasProduto = venda.getItens().get(0).getProduto().getCategoria().getNome();
            String nomeVendedor = venda.getVendedor().getDepartamento().getGerente().getNome();

            // Mais código usando estas informações...
        }

        return relatorio;
    }
}

Código aderente à Lei de Demeter e ao TDA:

@Service
public class RelatorioVendasService {

    private final VendaRepository vendaRepository;

    public RelatorioVendasService(VendaRepository vendaRepository) {
        this.vendaRepository = vendaRepository;
    }

    public RelatorioMensal gerarRelatorioMensal(Long lojaId, int mes, int ano) {
        List<Venda> vendas = vendaRepository.findByLojaIdAndPeriodo(lojaId, mes, ano);

        RelatorioMensal relatorio = new RelatorioMensal(lojaId, mes, ano);

        // Delegamos a responsabilidade para a entidade Venda
        for (Venda venda : vendas) {
            relatorio.adicionarVenda(venda);
        }

        return relatorio;
    }
}

@Entity
public class Venda {
    // atributos e outros métodos

    public void adicionarAoRelatorio(RelatorioMensal relatorio) {
        // A Venda conhece sua própria estrutura e sabe como
        // extrair informações relevantes
        relatorio.adicionarValorVenda(this.valor);
        relatorio.registrarFormaPagamento(this.formaPagamento);

        for (ItemVenda item : this.itens) {
            item.adicionarAoRelatorio(relatorio);
        }

        this.vendedor.adicionarEstatisticasAoRelatorio(relatorio);
    }
}

public class ItemVenda {
    // atributos e outros métodos

    public void adicionarAoRelatorio(RelatorioMensal relatorio) {
        relatorio.adicionarItem(
            this.quantidade, 
            this.valorUnitario, 
            this.produto.obterInformacaoResumida()
        );
    }
}

public class Vendedor {
    // atributos e outros métodos

    public void adicionarEstatisticasAoRelatorio(RelatorioMensal relatorio) {
        relatorio.registrarVendedor(this.id, this.nome);
        relatorio.adicionarComissao(this.calcularComissao());

        // O Vendedor sabe como obter informações do departamento sem expor
        // a estrutura interna do departamento
        relatorio.registrarDepartamento(this.obterInformacaoDepartamento());
    }

    public String obterInformacaoDepartamento() {
        // Encapsula acesso à cadeia de objetos
        return this.departamento.obterInformacaoCompleta();
    }
}

No exemplo aderente à Lei de Demeter, cada objeto é responsável pelo seu próprio comportamento e por conhecer sua estrutura interna. O serviço não precisa navegar por cadeias de objetos, pois cada entidade sabe como extrair e fornecer suas próprias informações, seguindo o princípio "Tell, Don't Ask".

A Lei de Demeter é frequentemente resumida como "só fale com seus amigos imediatos, não com os amigos dos seus amigos". Essa abordagem reduz o acoplamento entre componentes, facilita a manutenção e promove um melhor encapsulamento, complementando perfeitamente o princípio TDA.

Críticas e Limitações dos Princípios

Apesar de seus evidentes benefícios, é importante reconhecer que cada um destes princípios tem suas limitações e críticas relevantes. Aplicá-los sem considerar o contexto específico pode resultar em problemas.

Críticas ao DRY

Acoplamento indesejado: A busca pela eliminação de toda duplicação pode criar acoplamento entre componentes que deveriam ser independentes. Quando partes do sistema que evoluem por razões diferentes compartilham código, mudanças em uma parte podem afetar outras desnecessariamente.
Abstração prematura: Para eliminar duplicação, frequentemente criamos abstrações que são difíceis de entender e podem ser mais complexas que a duplicação original. Isso levou ao princípio alternativo WET (Write Everything Twice ou "Escreva Tudo Duas Vezes"), sugerindo que alguma duplicação controlada pode ser preferível a abstrações inadequadas.
Repetição acidental vs. essencial: Nem toda semelhança no código representa uma verdadeira duplicação conceitual. Por vezes, partes do código parecem similares mas têm propósitos distintos e podem evoluir em direções diferentes.

Críticas ao KISS

Subjetividade da simplicidade: O que é "simples" para um desenvolvedor pode ser complexo para outro. Essa subjetividade dificulta a aplicação consistente do princípio.
Simplificação excessiva: Em sistemas intrinsecamente complexos, soluções excessivamente simplificadas podem não abordar adequadamente a complexidade inerente do domínio.
Compromisso com desempenho: Soluções mais simples podem não oferecer o desempenho ideal. Em sistemas com requisitos rigorosos de performance, o KISS pode conduzir a soluções subótimas.

Críticas ao YAGNI

Dívida técnica estrutural: Seguir YAGNI estritamente pode resultar em arquiteturas difíceis de adaptar posteriormente. Algumas decisões arquiteturais fundamentais são difíceis de modificar uma vez que o sistema está em produção.
Custo de retrabalho: Se uma funcionalidade inicialmente adiada realmente se torna necessária, o custo de implementá-la posteriormente pode ser significativamente maior do que teria sido se incorporada desde o início.
Conhecimento do domínio: Em domínios bem estabelecidos, desenvolvedores experientes podem prever com razoável precisão quais funcionalidades serão necessárias, tornando o YAGNI menos relevante.

Críticas ao TDA

Classes sobrecarregadas: Uma aplicação estrita do TDA pode resultar em classes com múltiplas responsabilidades, violando o Princípio de Responsabilidade Única (SRP).
Incompatibilidade com paradigmas funcionais: Em programação funcional ou em designs orientados a dados, o TDA pode ser inadequado ou simplesmente não aplicável.
Desafios com aspectos transversais: Funcionalidades como logging, segurança ou auditoria frequentemente necessitam "perguntar" sobre o estado interno dos objetos para funcionar adequadamente.

Como observado pelo arquiteto de software Sebastian Malaca, "princípios são genéricos e livres de contexto, mas soluções reais são baseadas em contexto, então ajuste os princípios ao contexto, não o contrário". Esta é uma perspectiva valiosa para considerar durante a aplicação destes princípios.

Integrando os Princípios em seu Desenvolvimento

Estes quatro princípios (DRY, KISS, YAGNI e TDA) não existem isoladamente - eles se complementam e, quando aplicados com discernimento, criam uma abordagem holística para o desenvolvimento de software de qualidade.

Como os princípios se relacionam?

DRY + KISS: A eliminação de duplicação (DRY) frequentemente resulta em soluções mais simples (KISS).
KISS + YAGNI: Manter a simplicidade (KISS) muitas vezes envolve evitar adicionar funcionalidades desnecessárias (YAGNI).
YAGNI + TDA: Concentrar-se apenas no necessário no momento (YAGNI) conduz a um design onde objetos têm responsabilidades claras e bem definidas (TDA).
TDA + DRY: Quando objetos são responsáveis por seu próprio comportamento (TDA), torna-se mais fácil evitar duplicação de lógica (DRY).

Implementando na Prática

Comece com KISS: Ao iniciar qualquer componente, busque a solução mais simples e direta possível.
Aplique YAGNI: Questione cada funcionalidade proposta: "É necessária agora?". Se a resposta for negativa, postergue sua implementação.
Refatore para DRY: À medida que o código evolui, identifique duplicações e refatore para eliminar redundâncias.
Estruture com TDA: Organize seu código orientado a objetos para que cada classe seja responsável por seu próprio comportamento.
Use discernimento: Lembre-se que princípios são diretrizes, não regras absolutas. Saiba quando ser flexível e adaptá-los ao contexto específico.

Conclusão

Os princípios DRY, KISS, YAGNI e TDA não são apenas técnicas de codificação - são uma filosofia de desenvolvimento que valoriza clareza, manutenção e eficácia. Quando você internaliza e aplica esses princípios, eles mudam não só o código que você escreve, mas também a maneira como você pensa sobre os problemas de software.

No mundo atual, onde a complexidade técnica cresce a cada dia, a habilidade de manter a simplicidade enquanto resolve problemas complexos é um diferencial valioso. Esses princípios dão um caminho confiável para alcançar esse equilíbrio difícil, desde que você os veja como guias e não como regras absolutas.

Lembre-se: os princípios existem para nos servir, não o contrário. O desenvolvedor maduro sabe quando aplicá-los rigorosamente e quando adaptá-los (ou até mesmo quebrá-los de propósito) para servir a um objetivo maior no design do sistema.

Como Leonardo da Vinci disse há séculos, "a simplicidade é o último grau de sofisticação". No desenvolvimento de software, essa verdade continua valendo, mas o caminho para a simplicidade nem sempre é fácil - exige discernimento, experiência e sabedoria para aplicar os princípios certos, na hora certa, do jeito certo.

Referências Bibliográficas

Hunt, A., & Thomas, D. (1999). The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley Professional.
Martin, R. C. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall.
Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley Professional.
Fowler, M. (2018). Refactoring: Improving the Design of Existing Code (2nd ed.). Addison-Wesley Professional.
Freeman, S., & Pryce, N. (2009). Growing Object-Oriented Software, Guided by Tests. Addison-Wesley Professional.
Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional.
McConnell, S. (2004). Code Complete: A Practical Handbook of Software Construction (2nd ed.). Microsoft Press.
Castilho, R. (2014). Tell, don't ask. [Blog]. Disponível em: https://robsoncastilho.com.br/2014/05/11/conceitos-tell-dont-ask/
Souza, U. (2022). KISS, YAGNI, DRY – três princípios que todo desenvolvedor deveria conhecer! DEV Community. Disponível em: https://dev.to/urielsouza29/kiss-yagni-dry-tres-principios-que-todo-desenvolvedor-deveria-conhecer-47gg
Thiagomr. (2020). Desvendando o mundo mágico dos acrônimos: SOLID, KISS, YAGNI, DRY, DDD, TDD. DEV Community. Disponível em: https://dev.to/thiagomr/desvendando-o-mundo-magico-dos-acronimos-solid-kiss-yagni-dry-ddd-tdd-2onp
Lazaros. (2023). Conheça os 6 princípios essenciais para arquitetura de um software. Disponível em: https://www.lazaros.com.br/blog/6-principios-arquitetura-software/
Prado, L. P. (2017). O princípio Tell, Don't Ask. [Blog]. Disponível em: https://luizpauloprado.com.br/2017/01/04/o-principio-tell-dont-ask/
Fonseca Chaves, G. (2020). Conceito Tell, Don't Ask. LinkedIn. Disponível em: https://pt.linkedin.com/pulse/conceito-tell-dont-ask-guilherme-fonseca-chaves
Silva, R. (2019). Princípio Tell, Don't Ask. [Blog]. Disponível em: https://ramonsilva.net/post/princípio-tell-don-t-ask

Padronizando Commits Git com um Script Bash: Uma Solução Simples para um Problema Comum

Diego de Sousa Brandão — Mon, 28 Apr 2025 19:11:51 +0000

Índice

O que são Commits Semânticos e por que são importantes
A origem do problema
A solução: um hook Git em Bash
Anatomia do script
- O hook de validação
- O gerenciador de hooks
Instalação e uso
Conclusão e lições aprendidas
FAQ - Perguntas Frequentes
Próximos passos
Referências Bibliográficas

O que são Commits Semânticos e por que são importantes

Commits semânticos são uma convenção para escrever mensagens de commit padronizadas que comunicam claramente a intenção por trás de cada mudança no código. Esta abordagem surgiu da Convenção de Commits Convencionais (Conventional Commits), que por sua vez foi inspirada no Angular Commit Guidelines, utilizado pelo time do Google no desenvolvimento do Angular.

A ideia central é que cada commit deve descrever explicitamente seu propósito através de um formato estruturado:

tipo(escopo): descrição

Origem e Evolução

A convenção de commits semânticos ganhou popularidade por volta de 2015-2016, quando equipes de desenvolvimento começaram a perceber a necessidade de padronizar as mensagens de commit para facilitar a automação de processos como geração de changelogs e versionamento semântico. Inicialmente adotada por projetos JavaScript, a prática se espalhou para diversas linguagens e ecossistemas.

Tipos de Commits

Cada mensagem de commit começa com um "tipo" que indica a natureza da mudança:

feat: introduz uma nova funcionalidade no código
fix: corrige um bug ou problema
docs: alterações apenas na documentação
style: mudanças que não afetam o significado do código (espaços, formatação, etc.)
refactor: alteração de código que não corrige um bug nem adiciona uma feature
perf: melhoria de performance
test: adição ou correção de testes
build: alterações no sistema de build ou em dependências externas
ci: mudanças nos arquivos de configuração de CI/CD
chore: outras alterações que não modificam src ou arquivos de teste
revert: reverte um commit anterior

Onde:

escopo: opcional, indica a parte do código afetada
descrição: explica o que foi feito

Esta convenção traz diversos benefícios:

Legibilidade: Qualquer pessoa consegue entender rapidamente o propósito de um commit
Automatização: Permite gerar changelogs e versionamento semântico automaticamente
Organização: Facilita filtrar commits por tipo (apenas correções, apenas novas features)
Histórico significativo: Transforma o histórico de commits em uma documentação valiosa

Em equipes grandes ou projetos de longo prazo, essa padronização se torna ainda mais crucial, pois ajuda a manter todos alinhados sobre as mudanças realizadas.

A origem do problema

Ao trabalhar em projetos com múltiplos desenvolvedores, percebi a importância de manter um histórico de commits organizado e informativo.

Minha motivação principal para criar este script veio de minha experiência anterior como desenvolvedor full stack, quando tive a oportunidade de implementar o Husky no ecossistema Node.js - uma ferramenta que simplesmente "trava" commits que não seguem o padrão desejado. Após ver o impacto positivo dessa prática, eu queria algo igualmente eficaz e simples para meus projetos Java atuais, sem necessidade de configurações complexas ou dependências adicionais.

Embora existam algumas ferramentas semelhantes, como o JHusky (uma versão Java inspirada no Husky original) e alguns plugins Maven para hooks Git, descobri que muitas dessas soluções exigiam dependências específicas ou se integravam profundamente apenas com um único ecossistema. Eu queria algo verdadeiramente leve e portátil, que funcionasse em qualquer ambiente de desenvolvimento, independentemente das tecnologias utilizadas no projeto.

Foi aí que decidi criar minha própria ferramenta usando Bash, uma linguagem disponível em praticamente qualquer ambiente de desenvolvimento, permitindo que equipes com tecnologias mistas pudessem aproveitar os benefícios de padronização de commits sem precisar instalar ferramentas específicas de linguagem.

A solução: um hook Git em Bash

Decidi então criar uma solução simples: um script Bash que instala um Git hook para validar mensagens de commit, garantindo que elas sigam o padrão de commits semânticos.

Por que Bash? Porque está disponível em praticamente qualquer sistema Unix-like, não requer dependências externas, e qualquer desenvolvedor consegue modificá-lo para suas necessidades específicas.

Apresentação do Script

O script que desenvolvi tem duas partes principais: o hook commit-msg que faz a validação propriamente dita, e um gerenciador para instalar/remover esse hook em repositórios Git.

Aqui está o que ele faz:

Cria um hook commit-msg que valida mensagens de commit usando expressões regulares
Mostra feedbacks visuais coloridos quando o commit é rejeitado
Fornece exemplos corretos para ajudar o desenvolvedor
Permite instalar o hook em um repositório específico ou em todos os repositórios do sistema
Oferece uma interface amigável para gerenciar os hooks

Anatomia do script

O hook de validação

A parte principal do script é o hook em si, que valida a mensagem de commit usando uma expressão regular:

pattern="^(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert)(\([a-zA-Z0-9_-]+\))?: .{1,}"

if ! [[ $commit_msg =~ $pattern ]]; then
    # Exibe mensagem de erro formatada com instruções
    # ...
    exit 1
fi

Esta expressão regular garante que cada commit comece com um tipo válido (feat, fix, docs, etc.), opcionalmente seguido por um escopo entre parênteses, e depois por uma descrição.

Quando uma mensagem não segue esse padrão, o script exibe uma mensagem de erro colorida que explica o formato correto e mostra exemplos:

draw_box "ERRO: Mensagem de commit não segue o padrão semântico!" "$RED"
echo -e "\n$RED""Seu commit:$RESET $commit_msg"
echo -e "\n$YELLOW$BOLD""O formato correto é:$RESET <tipo>(<escopo>): <descrição>"
# ... explicação dos tipos válidos ...
echo -e "\n$BOLD$GREEN""Exemplos:$RESET"
draw_box "feat(login): adiciona validação de e-mail" "$GREEN"

Exemplo: A mensagem será exibida na aba de console do Git.

Exemplos rápidos

❌ Commits não semânticos (incorretos)	✅ Commits semânticos (corretos)
"Corrigido o bug de login"	`fix(auth): corrige validação de senha na tela de login`
"Adicionado novo botão"	`feat(ui): adiciona botão de exportar na tela de relatórios`
"Atualizando documentação"	`docs(readme): atualiza instruções de instalação`
"Melhorias no código"	`refactor(core): simplifica lógica de processamento de pagamentos`

O gerenciador de hooks

O script principal oferece uma interface de menu para:

Instalar o hook em um repositório específico ou globalmente
Remover hooks de um repositório específico ou globalmente
Sair do script

O menu é simples e intuitivo:

echo -e "${CYAN}===== ${BOLD}Gerenciador de Git Hook ($HOOK_NAME)${RESET}${CYAN} =====${RESET}"
echo -e "${BLUE}1)${RESET} ${BOLD}Instalar hook${RESET}"
echo -e "${BLUE}2)${RESET} ${BOLD}Remover hook${RESET}"
echo -e "${BLUE}3)${RESET} ${BOLD}Sair${RESET}"

Ao selecionar as opções 1 ou 2, você é apresentado a submenus que permitem escolher entre operações em um repositório específico ou em todos os repositórios do sistema.

Instalação e uso

A instalação do script é simples:

# Clone o repositório
git clone https://github.com/diegoSbrandao/git-hook-manager.git
cd git-hook-manager

# Torne o script executável
chmod +x install-windows-hook.sh

# Execute o script
./install-windows-hook.sh

Após executar o script, você verá um menu interativo:

===== Gerenciador de Git Hook (commit-msg) =====
1) Instalar hook
2) Remover hook
3) Sair
Escolha uma opção:

Opções do menu:

1) Instalar Hook

1.1) Instalar hook a partir de um caminho: Para adicionar o hook em um repositório específico.
1.2) Instalar hook em todos os repositórios do sistema: Para uma instalação global.

2) Remover Hook

2.1) Remover hook de um repositório específico: Remove apenas hooks instalados por este script.
2.2) Remover hooks de todos os repositórios do sistema: Para remoção global.

O script foi desenvolvido para ser compatível com Linux, macOS, WSL e Git Bash no Windows, exigindo apenas requisitos básicos como bash, find e grep, que geralmente já estão disponíveis nestes sistemas.

Conclusão e lições aprendidas

O que aprendi com essa experiência é que às vezes soluções simples resolvem problemas complexos. O script não passa de 150 linhas de código Bash, mas teve um impacto significativo na qualidade do nosso trabalho.

Também aprendi que padronização traz consistência, e consistência facilita a colaboração. Quando todos seguem o mesmo padrão, a comunicação flui melhor.

Por fim, aprendi que ferramentas que ajudam os desenvolvedores a seguir boas práticas são tão importantes quanto as boas práticas em si. Não adianta estabelecer regras se não facilitamos o cumprimento delas.

FAQ - Perguntas Frequentes

Q: O script impede commits que não sejam semânticos?

A: Sim, o hook rejeita automaticamente commits inválidos e exibe uma mensagem de erro explicativa com exemplos corretos.

Q: É possível personalizar os tipos de commit aceitos?

A: Sim, você pode editar o script e modificar a expressão regular que define os tipos válidos.

Q: O script funciona em ambientes Windows?

A: Sim, ele é compatível com Git Bash e WSL (Windows Subsystem for Linux) no Windows.

Q: A instalação afeta todos os meus repositórios automaticamente?

A: Não, você precisa escolher se deseja instalar em um repositório específico ou em todos, dando controle total ao usuário.

Q: O hook afeta commits já realizados?

A: Não, o hook valida apenas novos commits, não alterando o histórico existente.

Próximos passos

É importante destacar que este script está atualmente em versão beta e ainda está em desenvolvimento. Como parte dos planos futuros, pretendo expandir sua funcionalidade integrando-o como um plugin para Maven ou IntelliJ IDEA, tornando-o ainda mais acessível para desenvolvedores Java.

Quando estas versões estiverem disponíveis, atualizarei esta documentação com as novas informações e instruções de uso. Se você tem interesse em contribuir com este projeto ou tem sugestões para estas futuras implementações, não hesite em entrar em contato ou abrir uma issue no repositório.

Referências Bibliográficas

CHACON, S.; STRAUB, B. Pro Git. 2. ed. Apress, 2014. Disponível em: https://git-scm.com/book/en/v2
CONVENTIONAL COMMITS. Conventional Commits 1.0.0. Disponível em: https://www.conventionalcommits.org/

Nota: O projeto está licenciado sob a MIT License e está disponível em: https://github.com/diegoSbrandao/git-hook-manager.git. Sinta-se à vontade para adaptar às necessidades do seu projeto ou equipe. E se tiver sugestões de melhorias, ficarei feliz em recebê-las!

ArchUnit: Garantindo a Integridade Arquitetural de Aplicações Java

Diego de Sousa Brandão — Wed, 23 Apr 2025 02:39:45 +0000

Índice

Introdução
O que o ArchUnit faz?
Por que é importante?
- Documentação Executável
- Feedback Rápido
- Refatoração Segura
- Padronização em Equipes Distribuídas
- Evolução Controlada
Começando com ArchUnit
- Configuração do Projeto
- Escrevendo seu Primeiro Teste
- Executando os Testes
Exemplos Práticos
- Arquitetura em Camadas
- Arquitetura Limpa
Recursos Avançados do ArchUnit
- Regras Personalizadas Complexas
- Verificação de Interfaces e Herança
- Detecção de Ciclos de Dependência
- Cache de Importação
- Mensagens de Erro Personalizadas
- Utilizando Regras Pré-definidas
- Verificando Convenções de Nomenclatura
- Congelamento de Regras para Projetos Legados
Conclusão
Referência Bibliográfica

Introdução

Em projetos de software de médio e grande porte, garantir que o código siga os padrões arquiteturais definidos é um desafio contínuo. Conforme o código cresce e mais desenvolvedores participam do projeto, torna-se cada vez mais difícil manter a consistência arquitetural. É nesse contexto que o ArchUnit surge como uma ferramenta poderosa para desenvolvedores Java.

ArchUnit é uma biblioteca Java de código aberto que possibilita testar de forma automatizada se o código segue as regras arquiteturais estabelecidas. Ao contrário de ferramentas de análise estática tradicionais, o ArchUnit permite que você defina regras específicas para seu domínio e integre os testes de arquitetura diretamente na sua suíte de testes unitários.

O que o ArchUnit faz?

O ArchUnit permite que você teste aspectos como:

Dependências entre pacotes e classes: Garantir que camadas específicas não dependam de outras camadas indevidamente.
Convenções de nomenclatura: Certificar que nomes de classes e métodos sigam os padrões estabelecidos.
Uso adequado de anotações: Verificar se anotações específicas estão presentes onde deveriam estar.
Acesso a métodos e campos: Verificar que determinados métodos ou campos só são acessados em contextos específicos.
Estrutura de herança: Garantir que certas classes herdem ou implementem interfaces específicas.
Ciclos de dependência: Identificar e evitar ciclos de dependência que possam comprometer a manutenibilidade.
Validação de padrões arquiteturais conhecidos: Testar a conformidade com padrões como Arquitetura em Camadas, Arquitetura Limpa, etc.

Por que é importante?

A importância do ArchUnit vai além da simples verificação de código:

1. Documentação Executável

O ArchUnit transforma decisões arquiteturais em testes executáveis, servindo como documentação viva do projeto. Novos membros da equipe podem entender rapidamente as convenções arquiteturais examinando os testes.

2. Feedback Rápido

Ao integrar testes de arquitetura na sua pipeline de CI/CD, você recebe feedback imediato quando uma mudança no código viola as regras arquiteturais estabelecidas, prevenindo a degradação gradual da arquitetura.

3. Refatoração Segura

Durante grandes refatorações, o ArchUnit pode garantir que as mudanças respeitem as regras arquiteturais, dando confiança para evoluir o código com segurança.

4. Padronização em Equipes Distribuídas

Em equipes grandes ou distribuídas, o ArchUnit ajuda a manter consistência nas práticas de desenvolvimento, mesmo quando a comunicação direta entre equipes é limitada.

5. Evolução Controlada

Quando a arquitetura precisa evoluir, você pode atualizar os testes de arquitetura para refletir as novas diretrizes, facilitando a transição controlada de um padrão arquitetural para outro.

Começando com ArchUnit

Vamos ver como configurar e começar a usar o ArchUnit em um projeto Java:

Configuração do Projeto

Para Maven (pom.xml):

<!-- Dependência principal do ArchUnit -->
<dependency>
    <groupId>com.tngtech.archunit</groupId>
    <artifactId>archunit-junit5</artifactId>
    <version>1.4.0</version>
    <scope>test</scope>
</dependency>

Para Gradle (build.gradle):

dependencies {
    testImplementation 'com.tngtech.archunit:archunit-junit5:1.4.0'
}

Escrevendo seu Primeiro Teste

Depois de adicionar as dependências, você pode criar seu primeiro teste de arquitetura. Comece com algo simples:

package com.example.archunit;

import com.tngtech.archunit.core.domain.JavaClasses;
import com.tngtech.archunit.core.importer.ClassFileImporter;
import com.tngtech.archunit.lang.ArchRule;
import org.junit.jupiter.api.Test;

import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.classes;

public class ArchitectureTest {

    // Importando classes do seu projeto para análise
    JavaClasses importedClasses = new ClassFileImporter()
            .importPackages("com.example.project");

    @Test
    public void servicesShouldNotDependOnControllers() {
        // Definindo uma regra arquitetural
        ArchRule rule = classes()
                .that().resideInAPackage("..service..")
                .should().notDependOnClassesThat()
                .resideInAPackage("..controller..");

        // Verificando se a regra é respeitada
        rule.check(importedClasses);
    }
}

Este teste simples verifica se as classes no pacote service não dependem de classes no pacote controller, o que é uma regra comum em arquiteturas em camadas.

Executando os Testes

Para executar os testes de arquitetura:

Via Maven:

   mvn test

Via Gradle:

   ./gradlew test

Na sua IDE: Execute o teste como qualquer outro teste JUnit.

Se alguma regra for violada, você verá um erro no teste com uma mensagem detalhada explicando quais classes violaram a regra e como.

Por exemplo:

Architecture Violation [Priority: MEDIUM] - Rule 'classes that reside in a package '..service..' should not depend on classes that reside in a package '..controller..'' was violated (1 times):
Method com.example.project.service.UserService.getControllerData() calls method com.example.project.controller.UserController.getData()

Utilizando JUnit 5 para Simplificar os Testes

Se você estiver usando JUnit 5, pode simplificar ainda mais seus testes usando as anotações fornecidas pelo ArchUnit:

@AnalyzeClasses(packages = "com.example.project")
public class ArchitectureRulesTest {

    // O ArchUnit irá importar automaticamente as classes e verificar a regra
    @ArchTest
    static final ArchRule servicesShouldNotDependOnControllers = classes()
            .that().resideInAPackage("..service..")
            .should().notDependOnClassesThat()
            .resideInAPackage("..controller..");

    // Regras adicionais podem ser definidas como campos estáticos
    @ArchTest
    static final ArchRule repositoriesShouldBeAccessedOnlyByServices = classes()
            .that().resideInAPackage("..repository..")
            .should().onlyBeAccessedByClassesThat()
            .resideInAPackage("..service..");
}

Usando esta abordagem, não é necessário escrever explicitamente o código para importar as classes ou verificar as regras. O ArchUnit cuida disso automaticamente e também implementa um cache de classes entre os testes para melhorar o desempenho.

Exemplos Práticos

Vejamos dois exemplos práticos de como utilizar o ArchUnit para garantir a integridade de diferentes padrões arquiteturais:

Exemplo 1: Arquitetura em Camadas (Layered Architecture)

Este exemplo demonstra como validar uma arquitetura em camadas tradicional, comum em muitas aplicações:

import com.tngtech.archunit.core.domain.JavaClasses;
import com.tngtech.archunit.core.importer.ClassFileImporter;
import com.tngtech.archunit.library.Architectures;
import org.junit.jupiter.api.Test;

import static com.tngtech.archunit.library.Architectures.layeredArchitecture;

public class LayeredArchitectureTest {

    @Test
    public void testLayeredArchitecture() {
        JavaClasses importedClasses = new ClassFileImporter()
                .importPackages("com.mycompany.app");

        // Definindo a arquitetura em camadas usando o padrão predefinido
        Architectures.LayeredArchitecture layeredArchitecture = layeredArchitecture()
                // Definindo as camadas e os pacotes onde elas residem
                .layer("Controller").definedBy("..controller..")
                .layer("Service").definedBy("..service..")
                .layer("Repository").definedBy("..repository..")
                .layer("Domain").definedBy("..domain..")

                // Definindo as regras de dependência entre camadas
                .whereLayer("Controller").mayNotBeAccessedByAnyLayer()
                .whereLayer("Service").mayOnlyBeAccessedByLayers("Controller")
                .whereLayer("Repository").mayOnlyBeAccessedByLayers("Service")
                .whereLayer("Domain").mayOnlyBeAccessedByLayers("Service", "Repository");

        // Verificando a arquitetura
        layeredArchitecture.check(importedClasses);
    }
}

Este teste valida um padrão arquitetural em camadas típico onde:

Controllers ficam no topo da hierarquia e não devem ser acessados por outras camadas
Services podem ser acessados apenas pelos Controllers
Repositories podem ser acessados apenas por Services
O Domain (entidades) pode ser acessado por Services e Repositories

Exemplo 2: Arquitetura Limpa (Clean Architecture / Onion Architecture)

Este exemplo verifica a conformidade com os princípios da Arquitetura Limpa:

import com.tngtech.archunit.core.domain.JavaClasses;
import com.tngtech.archunit.core.importer.ClassFileImporter;
import org.junit.jupiter.api.Test;

import static com.tngtech.archunit.library.Architectures.onionArchitecture;

public class CleanArchitectureTest {

    @Test
    public void testCleanArchitecture() {
        JavaClasses importedClasses = new ClassFileImporter()
                .importPackages("com.mycompany.app");

        // Definindo a arquitetura limpa (onion architecture)
        // Note que esta funcionalidade está disponível no pacote com.tngtech.archunit.library
        onionArchitecture()
                // Definindo as camadas da arquitetura limpa
                .domainModels("..domain.model..")
                .domainServices("..domain.service..")
                .applicationServices("..application..")
                .adapter("persistence", "..adapter.persistence..")
                .adapter("rest", "..adapter.rest..")
                .adapter("cli", "..adapter.cli..")

                // A verificação é implícita: camadas internas não podem
                // depender de camadas externas
                .check(importedClasses);
    }
}

Este teste valida os princípios fundamentais da Arquitetura Limpa, onde:

O núcleo do domínio não depende de nenhuma outra camada
A camada de aplicação depende apenas do domínio
Os adaptadores (persistence, rest, cli) dependem da aplicação e do domínio

Note que a função onionArchitecture() é disponibilizada pelo pacote com.tngtech.archunit.library.Architectures, então certifique-se de incluir a dependência correta.

Recursos Avançados do ArchUnit

Além dos exemplos acima, o ArchUnit oferece recursos avançados que muitos desenvolvedores desconhecem:

Regras Personalizadas Complexas

Você pode criar regras de arquitetura altamente específicas usando a API fluente do ArchUnit:

ArchRule rule = classes()
    .that().areAnnotatedWith(RestController.class)
    .should().haveSimpleNameEndingWith("Controller")
    .andShould().bePublic()
    .andShould().onlyAccessMethodsThat(areDeclaredInController().or(areDeclaredInService()));

Verificação de Interfaces e Herança

Embora o ArchUnit não tenha suporte nativo direto para verificação de hierarquia completa, você pode verificar implementações de interfaces ou extensões de classes específicas:

// Verificando se todas as classes em um pacote implementam uma interface
ArchRule rule = classes()
    .that().resideInAPackage("..repository..")
    .should().implement(JpaRepository.class);

// Verificando se todas as classes que têm um determinado sufixo estendem uma classe base
ArchRule rule2 = classes()
    .that().haveSimpleNameEndingWith("Controller")
    .should().beAssignableTo(BaseController.class);

Detecção de Ciclos de Dependência

Os ciclos de dependência são um dos problemas arquiteturais mais difíceis de detectar manualmente:

ArchRule noCyclicDependencies = slices()
    .matching("com.mycompany.app.(*)..")
    .should().beFreeOfCycles();

Cache de Importação

Para melhorar a performance dos testes em bases de código grandes, o ArchUnit oferece opções de cache:

ClassFileImporter importer = new ClassFileImporter()
    .withImportOption(ImportOption.Predefined.DO_NOT_INCLUDE_TESTS)
    .withImportOption(ImportOption.Predefined.DO_NOT_INCLUDE_JARS);

JavaClasses classes = importer.importPackages("com.mycompany.app");

É importante notar que este cache funciona apenas durante a mesma execução de testes e não persiste entre diferentes execuções ou builds. Ele melhora a performance ao reutilizar as classes importadas na mesma execução dos testes.

Mensagens de Erro Personalizadas

Melhore a compreensão quando os testes falham:

ArchRule rule = classes()
    .that().areAnnotatedWith(Entity.class)
    .should().resideInAPackage("..domain.model..")
    .because("Entities são parte do modelo de domínio");

Utilizando Regras Pré-definidas

O ArchUnit fornece várias regras pré-definidas na classe GeneralCodingRules que podem ser utilizadas diretamente:

import static com.tngtech.archunit.library.GeneralCodingRules.*;

@ArchTest
static final ArchRule noClassesShouldUseJodaTime = NO_CLASSES_SHOULD_USE_JODATIME;

@ArchTest
static final ArchRule noClassesShouldUseStandardStreams = NO_CLASSES_SHOULD_ACCESS_STANDARD_STREAMS;

@ArchTest
static final ArchRule noClassesShouldThrowGenericExceptions = NO_CLASSES_SHOULD_THROW_GENERIC_EXCEPTIONS;

@ArchTest
static final ArchRule noClassesShouldUseJavaUtilLogging = NO_CLASSES_SHOULD_USE_JAVA_UTIL_LOGGING;

Observe que estas regras pré-definidas estão disponíveis no pacote com.tngtech.archunit.library, e não no core do ArchUnit. Certifique-se de incluir a dependência correta.

Verificando Convenções de Nomenclatura

Você pode garantir que suas convenções de nomenclatura sejam seguidas:

@ArchTest
static final ArchRule serviceClassesShouldHaveServiceSuffix = classes()
    .that().resideInAPackage("..service..")
    .should().haveSimpleNameEndingWith("Service");

@ArchTest
static final ArchRule repositoryClassesShouldHaveRepositorySuffix = classes()
    .that().resideInAPackage("..repository..")
    .should().haveSimpleNameEndingWith("Repository")
    .orShould().haveSimpleNameEndingWith("Dao");

Congelamento de Regras para Projetos Legados

Para equipes que trabalham com código legado, o ArchUnit oferece a funcionalidade de "congelamento" (freezing) de regras. Isso permite que você mantenha as violações existentes, mas impede novas violações:

// Criando uma regra normal
ArchRule rule = classes()
    .that().resideInAPackage("..service..")
    .should().notDependOnClassesThat()
    .resideInAPackage("..controller..");

// Congelando a regra para permitir violações existentes
FreezingArchRule frozenRule = FreezingArchRule.freeze(rule);

// Verificando apenas novas violações
frozenRule.check(importedClasses);

Esta técnica é extremamente útil quando você quer melhorar gradualmente a arquitetura de um sistema legado sem ter que corrigir todas as violações de uma só vez.

Conclusão

O ArchUnit representa um avanço significativo na forma como garantimos a qualidade arquitetural em projetos Java. Ao transformar regras arquiteturais em testes automatizados, ele ajuda a manter a integridade do código mesmo à medida que o projeto cresce e evolui.

A ferramenta não apenas detecta violações arquiteturais precocemente, mas também serve como documentação viva das decisões arquiteturais tomadas pela equipe. Isto facilita a adaptação de novos membros e garante consistência em equipes distribuídas.

Se você está enfrentando desafios para manter a consistência arquitetural em seu projeto Java, o ArchUnit pode ser uma adição valiosa ao seu conjunto de ferramentas de qualidade de código.

Para ver um exemplo prático de implementação dos conceitos apresentados neste artigo, você pode acessar o repositório Arquitetura em Camadas com ArchUnit que demonstra a aplicação desses princípios com exemplos de código e testes de arquitetura personalizados.

Referência Bibliográfica

Big O para Desenvolvedores Java: Entenda Complexidade de Algoritmos com Exemplos Reais

Diego de Sousa Brandão — Thu, 17 Apr 2025 14:22:41 +0000

O que é a Notação Big O e Por Que Deveria Me Importar?

Imagine que você está tentando escolher o melhor caminho para ir ao trabalho. Você tem várias opções: carro, ônibus, trem ou a pé. O tempo que cada opção leva depende da distância, mas também de outros fatores:

A pé: quanto mais longe, proporcionalmente mais tempo leva
De carro: em distâncias curtas é rápido, mas em longas distâncias pode enfrentar congestionamentos
De trem: tem um tempo fixo de espera, mas depois é rápido para distâncias longas

A notação Big O é como um sistema para classificar esses "caminhos" (algoritmos) com base em como eles se comportam quando precisam lidar com mais informações (distâncias maiores).

Em palavras simples: Big O nos diz o quanto um algoritmo vai ficar mais lento quando os dados aumentam.

Importante: Big O pode se referir tanto à complexidade de tempo (quanto tempo o algoritmo leva para executar) quanto à complexidade de espaço (quanta memória o algoritmo usa). Neste artigo, focamos principalmente na complexidade de tempo, mas mencionaremos a complexidade de espaço quando relevante.

Os Tipos Principais de Complexidade (Do Mais Rápido ao Mais Lento)

O(1) - Complexidade Constante: "Tempo Fixo"

Em linguagem simples: Não importa quanto os dados aumentem, o tempo continua o mesmo.

Exemplo do dia a dia: Acender ou apagar uma luz com um interruptor. Não importa o tamanho do cômodo, a ação de apertar o interruptor leva o mesmo tempo.

Exemplo em Java:

public static boolean isEven(int number) {
    return number % 2 == 0;  // Sempre uma operação, independente do número
}

O(log n) - Complexidade Logarítmica: "Divide e Conquista"

Em linguagem simples: Quando os dados dobram, o algoritmo só precisa de um pouquinho mais de tempo.

Exemplo do dia a dia: Procurar uma palavra no dicionário. Você abre no meio, decide se está antes ou depois, e elimina metade das páginas de uma vez.

Exemplo em Java - Busca binária:

public static int binarySearch(int[] array, int target) {
    int left = 0;
    int right = array.length - 1;

    while (left <= right) {
        int mid = left + (right - left) / 2;

        if (array[mid] == target)
            return mid;  // Encontrou!

        if (array[mid] < target)
            left = mid + 1;  // Procura na metade direita
        else
            right = mid - 1;  // Procura na metade esquerda
    }

    return -1;  // Não encontrou
}

O(n) - Complexidade Linear: "Olha Tudo Uma Vez"

Em linguagem simples: O tempo aumenta na mesma proporção que os dados. Dados duas vezes maiores = tempo duas vezes maior.

Exemplo do dia a dia: Ler um livro. Se o livro tiver o dobro de páginas, vai levar aproximadamente o dobro do tempo para ler.

Exemplo em Java - Encontrar o maior valor em um array:

public static int findMax(int[] array) {
    int max = array[0];

    for (int i = 1; i < array.length; i++) {
        if (array[i] > max) {
            max = array[i];
        }
    }

    return max;
}

O(n log n) - Complexidade Linearítmica: "Dividir, Ordenar e Juntar"

Em linguagem simples: Um pouco mais lento que linear, mas muito melhor que quadrático.

Exemplo do dia a dia: Organizar cartas de baralho usando o método "dividir em montes menores, ordenar cada monte e depois juntar".

Exemplo em Java - Merge Sort (algoritmo de ordenação eficiente):

public static void mergeSort(int[] array, int left, int right) {
    if (left < right) {
        // Encontra o meio do array
        int mid = left + (right - left) / 2;

        // Ordena as duas metades
        mergeSort(array, left, mid);
        mergeSort(array, mid + 1, right);

        // Junta as metades ordenadas
        merge(array, left, mid, right);
    }
}

A função merge combina as duas metades ordenadas em uma única sequência ordenada.

O(n²) - Complexidade Quadrática: "Compara Repetidamente"

Em linguagem simples: Muito mais lento quando os dados aumentam. Dados duas vezes maiores = tempo quatro vezes maior.

Exemplo do dia a dia: Verificar se há duplicatas em uma lista comparando cada item com todos os outros.

Exemplo em Java - Bubble Sort (algoritmo de ordenação simples mas ineficiente):

public static void bubbleSort(int[] array) {
    int n = array.length;

    for (int i = 0; i < n - 1; i++) {            
        for (int j = 0; j < n - i - 1; j++) {
            if (array[j] > array[j + 1]) {
                // Troca os elementos
                int temp = array[j];
                array[j] = array[j + 1];
                array[j + 1] = temp;
            }
        }
    }
}

O Bubble Sort compara repetidamente pares de elementos vizinhos e "borbulha" os maiores valores para o final do array em cada passada. É simples de entender, mas ineficiente para grandes conjuntos de dados.

O(2^n) - Complexidade Exponencial: "Explosão Combinatória"

Em linguagem simples: Fica absurdamente lento muito rápido. Cada elemento adicional praticamente dobra o tempo.

Exemplo do dia a dia: Tentar adivinhar uma senha testando todas as combinações possíveis.

Exemplo em Java - Calculando Fibonacci de forma recursiva ineficiente:

public static int fibonacci(int n) {
    if (n <= 1) {
        return n;
    }

    return fibonacci(n - 1) + fibonacci(n - 2);
}

Este código é extremamente ineficiente porque calcula os mesmos valores várias vezes. Para calcular fibonacci(5), ele acaba calculando fibonacci(2) três vezes!

Comparando as Velocidades

Para entender melhor o impacto dessas complexidades, vamos comparar quanto tempo (aproximadamente) cada uma levaria com diferentes tamanhos de entrada:

Complexidade	10 itens	100 itens	1000 itens
O(1)	1 segundo	1 segundo	1 segundo
O(log n)	3 segundos	7 segundos	10 segundos
O(n)	10 segundos	100 segundos	1000 segundos
O(n log n)	33 segundos	664 segundos	9970 segundos
O(n²)	100 seg	10000 seg	1000000 seg
O(2^n)	1024 seg	Muitos anos	Idade do universo

Importante: Os valores acima são apenas ilustrativos e servem para demonstrar a diferença de crescimento entre as complexidades. A notação Big O não mede tempo absoluto em segundos, e sim o comportamento relativo do algoritmo quando os dados aumentam.

Nota sobre casos: Neste artigo, estamos considerando o pior caso de complexidade para cada algoritmo, que é o cenário mais comum de análise em entrevistas e na prática. Muitos algoritmos podem ter desempenho melhor em certos cenários.

Por Que Isso É Importante Para Você

Mesmo se você está apenas começando a programar, entender o Big O te ajuda a:

Escrever programas mais rápidos: Escolher o algoritmo certo pode transformar um programa que demoraria horas em um que demora segundos.
Passar em entrevistas: Empresas de tecnologia adoram perguntar sobre Big O em entrevistas.
Entender quando seu código vai falhar: Saberá prever quando seu programa funciona bem com 100 itens mas falha com 10.000.
Fazer escolhas inteligentes: Algoritmos mais simples (como O(n²)) são mais fáceis de escrever, mas algoritmos mais eficientes (como O(n log n)) valem a pena para grandes conjuntos de dados.

Como Melhorar a Eficiência dos Seus Algoritmos

Use estruturas de dados apropriadas: Um HashMap pode transformar uma busca O(n) em O(1).
Memorize resultados intermediários: Se seu código calcula a mesma coisa várias vezes, guarde o resultado da primeira vez. Veja como podemos melhorar o Fibonacci:

public static int fibBetter(int n) {
    // Guarda resultados já calculados
    int[] memo = new int[n+1];
    return fibHelper(n, memo);
}

private static int fibHelper(int n, int[] memo) {
    if (n <= 1) return n;

    // Se já calculamos antes, só retorna o valor guardado
    if (memo[n] != 0) return memo[n];

    // Calcula e guarda para uso futuro
    memo[n] = fibHelper(n-1, memo) + fibHelper(n-2, memo);
    return memo[n];
}

Com esta técnica de memoization, o algoritmo passa de uma complexidade de O(2^n) para apenas O(n), um ganho gigantesco! Note também que criamos um array auxiliar, o que aumenta a complexidade de espaço para O(n).

Divida para conquistar: Quebre problemas grandes em problemas menores e resolva cada um separadamente.
Evite loops aninhados desnecessários: Dois loops aninhados geralmente significam O(n²).

Conclusão: Por Onde Começar?

O Big O pode parecer assustador no início, mas começar é simples:

Identifique os loops: Um único loop geralmente é O(n), loops aninhados geralmente são O(n²).
Reconheça padrões comuns: Busca binária é O(log n), algoritmos de ordenação geralmente são O(n log n) ou O(n²).
Pratique: Tente analisar o código que você já escreveu. Qual seria sua complexidade Big O?
Comece com eficiência razoável: Não se preocupe em otimizar tudo imediatamente. Comece com algo que funciona (mesmo que seja O(n²)) e melhore se for necessário.

Lembre-se: escrever um código que funciona é o primeiro passo. Fazê-lo eficiente é o segundo. O Big O te ajuda a entender quando o segundo passo é realmente necessário!

Dica Final

Se alguém lhe perguntar sobre a complexidade do seu algoritmo em uma entrevista, não tenha medo de pensar alto:

"Vejo que estou percorrendo o array uma vez, então isso é O(n)..."
"Aqui tenho dois loops aninhados, então estamos falando de O(n²)..."

Mostrar seu raciocínio é tão importante quanto chegar à resposta certa!

Para Quem Quer Saber Mais: Além do Big O

Embora o Big O seja o mais comum e o que você vai encontrar na maioria dos contextos, existem outras notações importantes:

Ω (Ômega): Representa o melhor caso (limite inferior). Por exemplo, a busca em um array pode ser O(n) no pior caso, mas é Ω(1) no melhor caso (quando o elemento está na primeira posição).
Θ (Theta): Representa quando o melhor e o pior caso coincidem. Um algoritmo é Θ(n) quando seu desempenho é sempre proporcional a n, sem variação significativa.

Na prática e em entrevistas, o foco geralmente é no Big O (pior caso) porque queremos garantir que nosso algoritmo funcione bem mesmo nas situações mais desafiadoras.

Comparação Visual das Complexidades

O gráfico acima mostra visualmente como as diferentes complexidades crescem à medida que o tamanho da entrada (n) aumenta:

O(1) permanece constante (linha horizontal azul)
O(log n) cresce muito lentamente (linha verde quase plana)
O(n) cresce de forma linear (linha amarela diagonal suave)
O(n log n) cresce um pouco mais rápido que linear (linha roxa)
O(n²) cresce rapidamente (linha vermelha subindo de forma acentuada)
O(2^n) cresce explosivamente (linha rosa quase vertical)

Observe como os algoritmos O(n²) e especialmente O(2^n) tornam-se rapidamente impraticáveis à medida que n aumenta, enquanto O(1) e O(log n) permanecem eficientes mesmo para grandes conjuntos de dados.

Referências Bibliográficas

TOSCANI, Laira Vieira; VELOSO, Paulo A. S. Complexidade de Algoritmos. Série de Livros Didáticos, Volume 13. Porto Alegre: Bookman, 2012.
BHARGAVA, Aditya Y. Entendendo Algoritmos: Um Guia Ilustrado Para Programadores e Outros Curiosos. São Paulo: Novatec Editora, 2017.
CORMEN, Thomas H.; LEISERSON, Charles E.; RIVEST, Ronald L.; STEIN, Clifford. Introduction to Algorithms. 3a ed. MIT Press, 2009.
MANZANO, José Augusto N. G.; OLIVEIRA, Jayr Figueiredo. Algoritmos: Lógica para Desenvolvimento de Programação de Computadores. 29a ed. São Paulo: Érica, 2019.
FEOFILOFF, Paulo. Algoritmos em Linguagem C. Rio de Janeiro: Elsevier/Campus, 2009.
REIS, Fábio dos. "O que é Notação Big O em programação e análise de algoritmos". Bóson Treinamentos em Ciência e Tecnologia. 24 ago. 2022. Disponível em: https://www.bosontreinamentos.com.br/estruturas-de-dados/o-que-e-notacao-big-o-em-programacao-e-analise-de-algoritmos/
BACKES, André Ricardo. Estruturas de Dados Descomplicada em Linguagem C. Rio de Janeiro: Elsevier, 2016.
SZWARCFITER, Jayme Luiz; MARKENZON, Lilian. Estruturas de Dados e seus Algoritmos. 3a ed. Rio de Janeiro: LTC, 2010.
ZIVIANI, Nivio. Projeto de Algoritmos com Implementações em Pascal e C. 3a ed. São Paulo: Cengage Learning, 2010.
SEDGEWICK, Robert; WAYNE, Kevin. Algorithms. 4a ed. Addison-Wesley Professional, 2011.

Você Está Tratando Exceções Errado? Descubra o Que Ninguém Te Conta Sobre Exceptions em Java! Part 2

Diego de Sousa Brandão — Tue, 08 Apr 2025 23:36:52 +0000

Parte 2 — Performance: O que Ninguém Te Conta Sobre Exceções em Java

Índice

Introdução
Stack Trace: O Verdadeiro Vilão
Exceções Estáticas vs. Dinâmicas
Otimizando: fillInStackTrace()
Stack Unwinding: O Custo de Lançar
Flags vs. Exceções
Exemplo: if vs. exceção
Exemplo: Exceções em loop
Análise Empírica: O Impacto das Exceções no Desempenho de APIs
- 9.1 Metodologia
- 9.2 Resultados Comparativos
- 9.3 Análise dos Resultados
- 9.4 Correlação com o Artigo Original
- 9.5 Considerações de Design
Conclusão
Referência Bibliográfica

Introdução

A primeira parte do nosso artigo abordou as boas práticas, armadilhas e fundamentos conceituais do uso de exceções em Java. Agora é hora de ir além e entender como elas afetam diretamente a performance da sua aplicação. E a resposta pode te surpreender.

Neste segundo artigo, vamos responder perguntas como:

Exceções realmente são lentas?
Qual o custo real de criar e lançar uma exceção?
Quando é aceitável usá-las?
E quando isso se torna uma armadilha silenciosa?

Com testes reais, benchmarks, código de exemplo e referências de peso como Aleksey Shipilev, você finalmente vai entender o que acontece debaixo dos panos.

Stack Trace: O Verdadeiro Vilão

Criar uma exceção com new Exception() não é apenas alocar um objeto. Na verdade, esse processo inclui capturar o stack trace completo do momento da instanciação, o que pode ser custoso.

O custo da captura do stack trace é proporcional à profundidade da pilha de chamadas. Quanto mais métodos estiverem empilhados, mais tempo o Java levará para construir a representação da pilha.

Exemplo real de benchmark:

Profundidade 0: ~2.0 microssegundos
Profundidade 1024: ~80 microssegundos

Em contrapartida, uma chamada simples a um método sem exceção pode custar menos de 1 nanossegundo!

Exceções Estáticas vs. Dinâmicas

Exceções criadas dinamicamente (com new) sempre carregam esse custo do stack trace. Já exceções estáticas, pré-criadas e reutilizadas, evitam esse custo.

private static final MinhaException EX = new MinhaException("Erro comum");

throw EX;

Esse padrão elimina o custo de instanciação, tornando o throw quase tão rápido quanto um return.

Otimizando: `fillInStackTrace()`

Outro truque é sobrescrever o método fillInStackTrace():

@Override
public synchronized Throwable fillInStackTrace() {
    return this;
}

Essa prática elimina a captura do stack trace. Resultado? Exceção extremamente leve — mas também muito mais difícil de depurar. Use com parcimônia.

Stack Unwinding: O Custo de Lançar

Lançar uma exceção (com throw) aciona o processo de desenrolamento da pilha, ou seja, a JVM precisa percorrer a pilha de chamadas até encontrar um catch adequado.

Se o catch estiver no mesmo método: ~230ns
Se estiver 10 níveis acima: pode chegar a ~8.000ns ou mais

Em contraste, um retorno normal entre esses mesmos métodos custa ~1ns.

Flags vs. Exceções

Um padrão comum para evitar exceções é usar flags ou wrappers como Optional.

public Optional<Usuario> buscar(String id) { ... }

Flags são constantes em desempenho.
Exceções são eficientes apenas quando raras.

Em baixa frequência (< 0.01%), exceções são aceitáveis e até mais rápidas. Em média ou alta frequência, o custo explode.

Exemplo: if vs. exceção

package org.example;

public class ExceptionVsIfSingleCall {
    public static void main(String[] args) {
        long start, end;

        // Controle com if
        start = System.nanoTime();
        processWithIf(3);
        end = System.nanoTime();
        System.out.println("Com if: 800 ns");

        // Controle com exceção
        start = System.nanoTime();
        try {
            processWithException(3);
        } catch (IllegalArgumentException e) {}
        end = System.nanoTime();
        System.out.println("Com exceção: 24100 ns");
    }

    public static int processWithIf(int value) {
        if (value < 5) return 0;
        return value;
    }

    public static void processWithException(int value) {
        if (value < 5) throw new IllegalArgumentException("valor inválido");
    }
}

O if foi mais de 30x mais rápido.

Exemplo: Exceções em loop

package org.example;

public class ExceptionOverheadLoopBenchmark {
    public static void main(String[] args) throws Exception {
        final int N = 10_000_000;

        long start, end;

        // Execução pura
        start = System.nanoTime();
        for (int i = 0; i < N ; i++) { int x = i * 2; }
        end = System.nanoTime();
        System.out.println("execução pura: 2.1322 ms");

        // If
        start = System.nanoTime();
        for (int i = 0; i < N ; i++) {
            if (i % 2 == 0) { int x = i * 2; }
        }
        end = System.nanoTime();
        System.out.println("if: 2.6529 ms");

        // Try-catch sem exceção
        start = System.nanoTime();
        for (int i = 0; i < N; i++) {
            try { int x = i * 2; } catch (Exception e) {}
        }
        end = System.nanoTime();
        System.out.println("try-catch (sem erro): 3.267699 ms");

        // Try-catch com exceção
        start = System.nanoTime();
        for (int i = 0; i < N / 100; i++) {
            try { throw new Exception("erro"); } catch (Exception e) {}
        }
        end = System.nanoTime();
        System.out.println("try-catch (com erro): 72.4698 ms");
    }
}

Exceções em loops não são apenas lentas: são destrutivas.

Análise Empírica: O Impacto das Exceções no Desempenho de APIs

Este estudo prático valida as conclusões do artigo "The Exceptional Performance of Lil' Exception" de Aleksey Shipilëv, testando duas implementações de API: uma utilizando exceções para sinalizar erros e outra utilizando um padrão de wrapper Result<T>.

Nota: Todos os códigos-fonte utilizados neste estudo, as evidências dos testes no JMeter e os scripts de teste estão disponíveis no repositório https://github.com/diegoSbrandao/diegoSbrandao-Exceptions-Java. Os resultados dos testes podem ser encontrados na pasta "Evidências" e os scripts do JMeter estão disponíveis para quem desejar reproduzir os experimentos.

Metodologia

Foram implementadas duas versões da mesma API com comportamento funcional idêntico:

Versão com Exceções: Utiliza RuntimeException e exceções customizadas para sinalizar erros
Versão com Wrapper: Utiliza o padrão Result<T> para encapsular sucesso ou falha

public class Result<T> {
    private final boolean success;
    private final T value;
    private final String errorMessage;

    // Construtor e métodos de fábrica
    public static <T> Result<T> success(T value) { ... }
    public static <T> Result<T> error(String message) { ... }
}

Ambas as APIs foram submetidas a testes de carga no Apache JMeter com as seguintes configurações:

20 threads (usuários concorrentes)
Período de aquecimento (ramp-up): 15 segundos
5 iterações por thread
Total: 300 solicitações (20 threads × 5 iterações × 3 execuções)

⚠️ Atenção: Os resultados de desempenho apresentados são específicos para o ambiente de hardware/software utilizado nos testes. Diferentes configurações de processador, memória, sistema operacional e JVM podem produzir variações significativas nos valores absolutos, embora as proporções relativas e conclusões gerais tendam a se manter. Ao reproduzir estes testes, considere as especificações do seu ambiente ao interpretar os resultados.

Resultados Comparativos

Métrica	API COM Exceções	API SEM Exceções	Diferença
Amostras	300	300	-
Tempo Médio (ms)	3	1	3× mais lento
Tempo Mínimo (ms)	2	1	2× mais lento
Tempo Máximo (ms)	194	4	48.5× mais lento
Desvio Padrão	11.13	0.58	19.2× mais variável
Taxa de Erro	0.00%	0.00%	-
Throughput	2.6/sec	2.6/sec	-

Análise dos Resultados

1. Tempo de Resposta

O tempo médio de resposta da API com exceções (3ms) é três vezes maior que a API usando o padrão Result (1ms), confirmando o overhead de processamento imposto pelas exceções.

2. Previsibilidade de Desempenho

O desvio padrão da API com exceções (11.13) é significativamente maior que o da API sem exceções (0.58), evidenciando uma variabilidade 19× maior. Esta inconsistência dificulta o planejamento de capacidade e prejudica a experiência do usuário.

3. Outliers e Picos de Latência

A diferença mais marcante está no tempo máximo de resposta: 194ms para exceções versus apenas 4ms para o padrão Result. Isso representa um pico de latência 48.5× maior, confirmando uma das conclusões mais importantes do artigo: as exceções podem causar picos de latência extremos inaceitáveis em aplicações sensíveis ao tempo.

4. Throughput Equivalente

O throughput manteve-se idêntico (2.6 req/s) em ambas as abordagens, indicando que em níveis normais de tráfego, a escolha entre exceções e wrappers não afeta diretamente a capacidade de processamento da API.

Correlação com o Artigo Original

Nossos resultados confirmam empiricamente várias conclusões do artigo "The Exceptional Performance of Lil' Exception":

Custo de Construção do Stack Trace: O artigo aponta que a construção do stack trace é um dos principais fatores de custo das exceções, o que explica nosso tempo médio 3× maior.
Variabilidade de Desempenho: O artigo menciona que o desempenho de exceções é imprevisível, confirmado pelo desvio padrão 19× maior em nossa API com exceções.
Picos de Latência: O artigo destaca que exceções podem causar picos extremos de latência, evidenciado pelo nosso tempo máximo 48.5× maior.
Regra Empírica de Frequência: O artigo sugere que exceções só são aceitáveis quando ocorrem com frequência inferior a 10⁻⁴ (0.01%). Nossos resultados mostram que mesmo com frequências baixas, o impacto nos picos de latência permanece significativo.

Considerações de Design

Quando usar Exceções:

Para condições verdadeiramente excepcionais (frequência < 0.01%)
Quando a simplicidade do código é mais importante que desempenho previsível
Em cenários onde picos ocasionais de latência são aceitáveis
Em situações que representam erros reais no fluxo de execução
Para casos excepcionais onde interromper o fluxo normal é apropriado

Exceções e o mecanismo de try-catch são extremamente úteis quando usados adequadamente. Eles melhoram a legibilidade do código, separam o fluxo principal do tratamento de erros, e permitem capturar problemas em níveis superiores da aplicação. Em casos genuinamente excepcionais, como falhas de sistema, erros de configuração ou condições inesperadas, as exceções são a ferramenta adequada e podem até melhorar o desempenho do caminho de execução normal.

Quando usar Wrappers (Result/Optional):

Para operações com falhas esperadas ou frequentes
Quando a previsibilidade de desempenho é crítica
Em serviços de alta disponibilidade onde P99 e P999 são monitorados
Em APIs de baixa latência onde picos são inaceitáveis
Para operações onde o "erro" é um resultado possível e esperado

Os resultados deste estudo prático validam as conclusões teóricas do artigo original: exceções impactam significativamente o desempenho e a previsibilidade de APIs. O padrão Result<T> demonstrou desempenho mais consistente e previsível, sem picos de latência, tornando-o mais adequado para sistemas sensíveis ao tempo e de alta disponibilidade.

Para aplicações onde a previsibilidade de desempenho é crítica, nossos dados sugerem fortemente a adoção de padrões alternativos às exceções, como o Result<T> implementado neste estudo.

Conclusão

Exceções têm dois custos principais: stack trace e stack unwinding.
Quanto mais profunda a pilha, maior o custo de criação da exceção.
Quanto mais distante o catch, maior o custo do throw.
Evite exceções em lógicas de validação comum ou em loops.
Use exceções para... exceções. Casos realmente raros e inesperados.

Exceções bem usadas otimizam o caminho "feliz". Mal usadas, penalizam toda sua aplicação.

Referência Bibliográfica

Aleksey Shipilev. Lil' Exception: Performance implications of exceptions
Joshua Bloch. Effective Java, 3ª edição.
Oracle Docs: https://docs.oracle.com/en/java/
Benchmarks próprios com System.nanoTime() e cenários reais.

Você Está Tratando Exceções Errado? Descubra o Que Ninguém Te Conta Sobre Exceptions em Java! Part 1

Diego de Sousa Brandão — Tue, 08 Apr 2025 23:36:08 +0000

📚 Índice

Introdução
O que são Exceções em Java?
Use exceções apenas para condições excepcionais
Use exceções verificadas para condições recuperáveis e exceções em tempo de execução para erros de programação
Evite o uso desnecessário de exceções verificadas
Prefira o uso de exceções padrão
Lance exceções apropriadas à abstração
Documente todas as exceções lançadas por cada método
Inclua informações úteis nas mensagens de erro
Busque a atomicidade em caso de falha
Nunca ignore exceções
Conclusão
📌 Curioso para ir mais fundo?
Referência Bibliográfica

Introdução

Imagine que sua aplicação falhe em produção, mas a mensagem de erro seja vaga, incompleta ou — pior ainda — esteja silenciosamente ignorada. Agora, imagine que o problema poderia ter sido detectado mais cedo, documentado melhor ou mesmo evitado. Se isso soa familiar, este artigo é para você.

Exceções em Java são uma das ferramentas mais subestimadas — e frequentemente mal utilizadas — por desenvolvedores. Apesar de sua importância para a robustez, legibilidade e manutenção de sistemas, o tratamento de exceções é muitas vezes feito com base em suposições ou padrões copiados sem reflexão.

Neste artigo, você entenderá:

O que realmente são exceções em Java.
Quando e por que usá-las.
As diferenças entre exceções verificadas e não verificadas.
Como projetar APIs que expõem exceções de forma eficaz.
Boas práticas baseadas em Effective Java, complementadas com exemplos práticos e fontes confiáveis como a documentação oficial da Oracle e experiências do mundo real.

Tudo isso com código explicativo (inspirado, mas não copiado do livro), comentários úteis e estrutura clara. Vamos desmistificar o tema, passo a passo.

O que são Exceções em Java?

Em Java, uma exceção é um mecanismo usado para indicar que ocorreu um erro durante a execução de um programa. Exceções são objetos que representam estados anormais de execução — algo que interrompe o fluxo normal do código.

Esses objetos pertencem à hierarquia da classe Throwable, que é dividida em três grandes grupos:

Throwable
├── Exception         → Usada para condições que o programa pode recuperar
│   ├── Checked       → Deve ser tratada com try/catch ou throws
│   └── Unchecked     → Subclasses de RuntimeException
└── Error             → Erros graves, geralmente lançados pela JVM

Exemplo: O fluxo normal e uma exceção

public void processarPagamento(double valor) {
    if (valor <= 0) {
        throw new IllegalArgumentException("O valor deve ser positivo");
    }
    // continua processamento...
}

Nesse exemplo, IllegalArgumentException sinaliza que houve uso incorreto da API, e isso não é recuperável pela lógica de negócio.

Use exceções apenas para condições excepcionais

Exceções devem ser utilizadas para representar situações anormais, inesperadas e que normalmente não fazem parte do fluxo padrão da aplicação. Usar exceções para controle de fluxo, por exemplo, além de um antipadrão, afeta negativamente a performance e a legibilidade.

❌ Exemplo Ruim: controle de fluxo com exceção

try {
    int i = 0;
    while (true) {
        processarElemento(lista.get(i++));
    }
} catch (IndexOutOfBoundsException e) {
    // fim da iteração
}

✅ Alternativa Correta

for (int i = 0; i < lista.size(); i++) {
    processarElemento(lista.get(i));
}

Por que isso é importante?

Exceções são caras em termos de desempenho (envolvem captura de stack trace).
Escondem bugs reais quando mal utilizadas.
Tornam o código mais difícil de entender.

Lembre-se:

"Use exceções para o inesperado, não para o inevitável."

Se a situação é comum ou previsível, use estruturas de controle tradicionais, como condicionais ou verificações explícitas.

Use exceções verificadas para condições recuperáveis e exceções em tempo de execução para erros de programação

Uma dúvida comum entre desenvolvedores Java é: quando devo criar uma exceção verificada e quando uma não verificada? Para responder a isso com precisão, precisamos entender o propósito de cada uma.

📌 Exceções Verificadas (Checked Exceptions)

São aquelas que o compilador obriga a tratar ou propagar com throws. Devem ser usadas para condições que fazem parte da lógica de negócio, mas que não ocorrem em todos os casos — e que o chamador pode e deve tratar.

✅ Exemplo de exceção verificada:

public class LimiteCreditoExcedidoException extends Exception {
    private final double excesso;

    public LimiteCreditoExcedidoException(double excesso) {
        super("Limite de crédito excedido: R$ " + excesso);
        this.excesso = excesso;
    }

    public double getExcesso() {
        return excesso;
    }
}

public void comprar(double valor) throws LimiteCreditoExcedidoException {
    if (valor > saldoDisponivel) {
        throw new LimiteCreditoExcedidoException(valor - saldoDisponivel);
    }
    saldoDisponivel -= valor;
}

Essa exceção é esperada e recuperável: o cliente pode tentar comprar com outro valor ou com outro meio de pagamento.

📌 Exceções Não Verificadas (Unchecked Exceptions)

São subclasses de RuntimeException. Indicam erros de programação, como violar contratos de métodos, passar argumentos inválidos, acessar índice fora do array etc. O objetivo dessas exceções é alertar para falhas lógicas que devem ser corrigidas — não tratadas em tempo de execução.

✅ Exemplo de exceção não verificada:

public void definirIdade(int idade) {
    if (idade < 0) {
        throw new IllegalArgumentException("Idade não pode ser negativa: " + idade);
    }
    this.idade = idade;
}

⚠️ Cuidado com situações ambíguas

Algumas situações podem parecer de negócio, mas são causadas por erros de uso da API. Exemplo: esgotamento de recursos.

Se previsível e tratável: use exceção verificada.
Se resultado de falha de projeto ou uso impróprio: use exceção não verificada.

Regra prática:

"Se o chamador pode agir de forma útil quando a exceção ocorre, torne-a verificada. Caso contrário, torne-a não verificada."

Erros (`Error`): quando usar?

Nunca. Exceto se for a própria JVM lançando. Error indica falhas como OutOfMemoryError, StackOverflowError ou InternalError. Não são feitas para captura, nem para lançar em código de aplicação.

Evite o uso desnecessário de exceções verificadas

Exceções verificadas, quando bem aplicadas, aumentam a robustez da aplicação, pois forçam o desenvolvedor a lidar com situações excepcionais. No entanto, seu uso excessivo pode tornar a API verbosa, desagradável de usar e até limitante em certos contextos, como em streams ou expressões lambda.

⚠️ Problema: excesso de checked exceptions

Imagine um método que lança uma exceção verificada para uma condição que o cliente não pode fazer nada para corrigir:

public void inicializar() throws ConfigFileNotFoundException {
    Path config = Paths.get("/etc/app/config.yml");
    if (!Files.exists(config)) {
        throw new ConfigFileNotFoundException("Arquivo de configuração ausente.");
    }
    // Continua a leitura...
}

Se a ausência do arquivo não pode ser resolvida pelo cliente, talvez essa devesse ser uma exceção não verificada, indicando erro de configuração no ambiente.

Alternativas ao uso de checked exceptions

✅ 1. Use Optional para indicar ausência de valor

public Optional<Usuario> buscarPorCpf(String cpf) {
    return repositorio.stream()
        .filter(u -> u.getCpf().equals(cpf))
        .findFirst();
}

Em vez de lançar UsuarioNaoEncontradoException, devolvemos um Optional que o cliente pode tratar como preferir:

usuarioService.buscarPorCpf("123")
    .ifPresentOrElse(
        this::processarUsuario,
        () -> logger.warn("Usuário não encontrado")
    );

✅ 2. Divida a lógica em método de verificação + execução

Antes:

try {
    dao.atualizar(cliente);
} catch (ClienteInvalidoException e) {
    // tratamento
}

Depois:

if (dao.podeAtualizar(cliente)) {
    dao.atualizar(cliente);
} else {
    logger.warn("Cliente inválido para atualização");
}

Essa abordagem é útil apenas quando o estado não muda entre as chamadas.

Quando usar exceções verificadas então?

Quando o chamador tem capacidade de tratar e agir.
Quando é possível fornecer informações úteis para recuperação.
Quando o uso correto da API ainda pode falhar por fatores externos.

Lembre-se: checked exceptions devem ter um propósito claro. Se você estiver usando apenas para "avisar" que algo falhou, talvez uma exceção não verificada ou um Optional seja mais apropriado.

Prefira o uso de exceções padrão

Um sinal claro de maturidade técnica é saber quando reutilizar o que já existe. O Java fornece uma ampla gama de exceções padrão bem definidas, documentadas e familiares à comunidade — usá-las corretamente reduz complexidade, facilita manutenção e melhora a legibilidade do seu código.

📌 Por que reutilizar exceções padrão?

Evita criar hierarquias de exceções desnecessárias
Desenvolvedores reconhecem imediatamente o que cada exceção significa
Menor consumo de memória e classes carregadas

Principais exceções padrão e quando usá-las

Exceção	Quando usar
`IllegalArgumentException`	Parâmetro com valor inaceitável
`IllegalStateException`	Estado atual do objeto é inválido para a operação
`NullPointerException`	Valor `null` onde não deveria existir (mas evite, prefira validação explícita)
`IndexOutOfBoundsException`	Índice fora dos limites válidos
`UnsupportedOperationException`	Método foi chamado mas não é suportado pela implementação
`ConcurrentModificationException`	Modificação simultânea de estrutura interna onde não permitido

✅ Exemplo:

public void setPorcentagemDesconto(double porcentagem) {
    if (porcentagem < 0 || porcentagem > 1) {
        throw new IllegalArgumentException("Porcentagem deve estar entre 0 e 1");
    }
    this.desconto = porcentagem;
}

⚠️ Quando NÃO reutilizar exceções padrão

Se a exceção representa uma regra de negócio específica (ex: SaldoInsuficienteException)
Se a exceção precisa carregar dados adicionais (ex: valor do saldo, ID de operação)
Se o nome da exceção padrão pode confundir ou não corresponder ao domínio da aplicação

✍️ Dica avançada

Você pode estender exceções padrão se quiser adicionar mais contexto:

public class PercentualInvalidoException extends IllegalArgumentException {
    public PercentualInvalidoException(double valor) {
        super("Valor inválido: " + valor);
    }
}

Use com moderação. Exceções são objetos serializáveis e impactam a estabilidade da API.

Lance exceções apropriadas à abstração

Ao construir APIs ou camadas de serviço, é comum interagir com bibliotecas de terceiros ou componentes de baixo nível (como JDBC, bibliotecas de rede, sistemas de arquivos, etc). Muitas vezes, essas bibliotecas lançam exceções específicas de sua implementação.

A pergunta é: devo propagar essa exceção para cima? Ou traduzi-la para algo mais significativo?

🚫 Errado: Vazar exceções de baixo nível

public void salvarDados(Cliente cliente) throws SQLException {
    connection.prepareStatement("...").execute();
}

O chamador agora precisa conhecer SQLException, mesmo que ele esteja em uma camada que não deveria saber que há banco de dados envolvido. Isso vincula sua API à implementação interna.

✅ Certo: Traduzir a exceção para o domínio da abstração

public void salvarDados(Cliente cliente) {
    try {
        connection.prepareStatement("...").execute();
    } catch (SQLException e) {
        throw new PersistenciaException("Erro ao salvar cliente no banco de dados", e);
    }
}

Agora, quem chama o método lida com PersistenciaException, que é coerente com a camada de aplicação, e não precisa conhecer detalhes do banco.

Essa técnica se chama tradução de exceção (exception translation). Ela desacopla as camadas e torna sua API mais estável.

🔗 Quando preservar a exceção original? Encadeamento (Exception Chaining)

Se a exceção original contém informações úteis para depuração, inclua-a como causa:

throw new MinhaExcecaoNegocial("Erro de negócio", causa);

Isso preserva o stack trace original e permite que depuradores ou logs vejam a origem real do problema, sem perder o contexto de negócio.

🧠 Regra prática:

Capture exceções de baixo nível
Traduza para exceções do domínio da sua camada
Mantenha a causa original (chaining), se for útil

Exceção com encadeamento personalizado

public class OperacaoFinanceiraException extends RuntimeException {
    public OperacaoFinanceiraException(String mensagem, Throwable causa) {
        super(mensagem, causa);
    }
}

Documente todas as exceções lançadas por cada método

Uma API bem projetada não é apenas intuitiva no uso, mas também transparente em relação ao que pode dar errado. Documentar as exceções que seus métodos podem lançar é parte essencial do contrato da API.

🧾 Por que documentar exceções?

Ajuda o consumidor da API a saber o que esperar.
Facilita o uso correto de blocos try/catch.
Deixa explícitas as pré-condições para o uso do método.

✅ Como documentar corretamente

Use a tag @throws no Javadoc para cada exceção que pode ser lançada:

/**
 * Calcula a média dos valores informados.
 * @param valores Lista de valores numéricos
 * @return média aritmética
 * @throws IllegalArgumentException se a lista estiver vazia
 * @throws NullPointerException se a lista for nula
 */
public double calcularMedia(List<Double> valores) {
    if (valores == null) {
        throw new NullPointerException("Lista não pode ser nula");
    }
    if (valores.isEmpty()) {
        throw new IllegalArgumentException("Lista não pode estar vazia");
    }
    return valores.stream().mapToDouble(Double::doubleValue).average().orElse(0);
}

Mesmo exceções não verificadas (unchecked) devem ser documentadas, mesmo que não apareçam no throws da assinatura.

❗ Evite generalizações perigosas

Nunca declare throws Exception ou throws Throwable, exceto em casos como o método main, que raramente é chamado por código da aplicação.

// ERRADO: não informa nada útil
public void processar() throws Exception { ... }

📚 Exceções em interfaces

Documentar exceções em métodos de interfaces é ainda mais importante, pois isso define o contrato que todas as implementações devem seguir.

/**
 * Busca cliente pelo CPF.
 * @param cpf CPF válido
 * @return cliente encontrado
 * @throws ClienteNaoEncontradoException se não houver cliente com o CPF informado
 */
Cliente buscarPorCpf(String cpf);

📝 Quando a exceção for comum a vários métodos

Se todos os métodos da classe podem lançar uma mesma exceção sob uma mesma condição, documente isso no comentário da classe:

/**
 * Todos os métodos desta classe lançam NullPointerException se qualquer argumento for nulo.
 */
public class ServicoCalculadora { ... }

Uma documentação clara de exceções faz sua API parecer profissional, robusta e confiável.

Inclua informações úteis nas mensagens de erro

Quando uma exceção é lançada, geralmente o que temos para entender o erro é o stack trace e a mensagem detalhada da exceção. Essa mensagem deve ser clara, informativa e, principalmente, útil para diagnóstico e correção.

⚠️ Problema: mensagens genéricas e inúteis

throw new IllegalArgumentException("Erro no parâmetro");

Essa mensagem diz o quê? Que parâmetro? Qual valor foi passado? Qual era o esperado? Nada disso está claro.

✅ Boa prática: inclua valores e contexto

throw new IllegalArgumentException(
    String.format("Idade inválida: %d. Esperado valor entre 0 e 150", idade)
);

Esse tipo de mensagem:

Facilita o rastreamento do bug
Reduz o tempo de investigação
Mostra o real motivo da falha

Exemplo com exceção customizada informativa

public class IntervaloInvalidoException extends RuntimeException {
    public IntervaloInvalidoException(int valor, int minimo, int maximo) {
        super(String.format(
            "Valor %d fora do intervalo permitido [%d, %d]",
            valor, minimo, maximo
        ));
    }
}

✍️ Dica: Inclua dados, não prosa excessiva

A mensagem deve ser objetiva. Evite longas descrições literárias. Exceções são ferramentas técnicas, não mensagens para usuários finais.

🔐 Segurança: cuidado com dados sensíveis

Jamais inclua:

Senhas
Tokens
Chaves privadas

Esses dados podem vazar em logs, telas ou relatórios.

🧠 Padrão sugerido:

"Minha exceção deve, no mínimo, informar qual dado causou o erro e qual era o valor esperado."

Busque a atomicidade em caso de falha

A atomicidade de falha significa que, se um método falhar, ele não deve deixar o objeto em um estado inconsistente. O ideal é que, após a exceção, o objeto esteja exatamente no mesmo estado que estava antes da chamada do método — como se nada tivesse acontecido.

🧱 Por que isso é importante?

Evita corrupção de estado
Facilita depuração
Mantém invariantes da classe
Permite tentativas futuras com segurança

✅ Estratégia 1: Verificar tudo antes de modificar

Valide os parâmetros e condições antes de alterar qualquer dado do objeto:

public void removerProduto(int index) {
    if (index < 0 || index >= produtos.size()) {
        throw new IndexOutOfBoundsException("Índice inválido: " + index);
    }
    produtos.remove(index);
}

✅ Estratégia 2: Ordenar operações para que falhas ocorram antes das alterações

Exemplo: validar permissões, checar pré-condições e só depois executar mutações.

✅ Estratégia 3: Usar cópias temporárias (fail-safe)

Modifique uma estrutura auxiliar e só depois aplique a mudança:

public void ordenar() {
    List<Item> copia = new ArrayList<>(itens);
    copia.sort(Comparator.comparing(Item::getNome));
    this.itens = copia; // só agora altera o estado
}

✅ Estratégia 4: Usar try-with-resources e finally

Quando há recursos externos (arquivos, conexões, etc), certifique-se de que eles sempre serão liberados:

try (FileReader reader = new FileReader("dados.txt")) {
    processar(reader);
} catch (IOException e) {
    logger.error("Falha na leitura", e);
}

Exemplo com finally:

FileInputStream in = null;
try {
    in = new FileInputStream("entrada.txt");
    ler(in);
} catch (IOException e) {
    logger.error("Erro", e);
} finally {
    if (in != null) {
        try { in.close(); } catch (IOException ignored) {}
    }
}

try-with-resources é sempre preferível ao finally para fechar recursos — mais limpo e seguro.

🧠 Nem sempre é possível

Se múltiplas threads acessam a mesma instância sem sincronização adequada, ou se a operação é distribuída (envolve banco ou rede), pode ser difícil garantir atomicidade. Ainda assim, documente claramente o comportamento esperado após a falha.

Regra prática:

“Se meu método lançar exceção, o objeto deve permanecer íntegro.”

Nunca ignore exceções

Ignorar exceções é como ignorar o alarme de incêndio — pode até parecer inofensivo no início, mas tem potencial para causar desastres. Quando um método lança uma exceção, ele está dizendo: "Algo deu errado e precisa da sua atenção".

❌ Exemplo perigoso:

try {
    arquivo.close();
} catch (IOException e) {
    // Ignorado
}

Esse bloco catch silencioso pode estar mascarando:

Problemas de disco
Arquivo em uso por outro processo
Falha de escrita que impede persistência de dados

✅ Abordagem correta: tratar ou registrar

try {
    arquivo.close();
} catch (IOException e) {
    logger.warn("Erro ao fechar arquivo", e);
}

✅ Se realmente precisar ignorar, explique o motivo:

try {
    recurso.close();
} catch (IOException ignored) {
    // OK: falha ao fechar recurso não afeta resultado da operação
}

🧠 Ignorar exceções pode:

Ocultar bugs graves
Corromper dados
Comprometer rastreamento de erros
Levar a comportamentos imprevisíveis em produção

Regra prática:

“Se você capturar uma exceção, faça algo com ela — trate, retransforme, registre ou repropague. Nunca simplesmente a ignore.”

Isso vale tanto para exceções verificadas quanto para as não verificadas. Mesmo um NullPointerException inesperado pode fornecer informações úteis sobre falhas de contrato na sua API.

Conclusão

Parabéns! Você chegou ao fim de uma jornada densa, mas extremamente valiosa sobre tratamento de exceções em Java. Se antes exceções pareciam apenas blocos try/catch espalhados pelo código, agora você sabe que elas são um pilar essencial da arquitetura de software bem projetada.

Mais do que saber "como" tratar uma exceção, você aprendeu "por que" cada escolha importa:

Quando lançar — e qual tipo usar?
Como documentar e encapsular erros sem esconder os problemas reais?
Como escrever mensagens úteis que ajudam na depuração?
Como manter o sistema íntegro, mesmo quando algo dá errado?

Tratar exceções corretamente é, acima de tudo, um sinal de maturidade no design. Não se trata de silenciar erros, mas de torná-los visíveis, compreensíveis e tratáveis.

Use exceções com intenção, empatia e responsabilidade. Seu futuro "eu" e sua equipe agradecem.

Se este conteúdo te ajudou, compartilhe com sua equipe, salve como referência para revisões de código e, principalmente, leve esse conhecimento para seus projetos do dia a dia.

📌 Curioso para ir mais fundo?

Na Parte 2, exploramos o que poucos falam: o impacto real de exceções na performance do seu sistema. Será que if realmente é mais rápido que throw? Quão caro é um try-catch dentro de um loop?

💡 Descubra benchmarks surpreendentes, truques internos da JVM e o que acontece por baixo dos panos quando você lança uma exceção.

👉 Clique aqui para ler a Parte 2 — Performance: O que Ninguém Te Conta Sobre Exceções em Java Part 2

Referência Bibliográfica

Aleksey Shipilev. Lil' Exception: Performance implications of exceptions
Joshua Bloch. Effective Java, 3ª edição.
Oracle Docs: https://docs.oracle.com/en/java/

O Princípio FIRST em Testes de Software

Diego de Sousa Brandão — Sat, 05 Apr 2025 19:27:16 +0000

Introdução

Robert C. Martin, mais conhecido como "Uncle Bob", é um dos nomes mais respeitados na área de desenvolvimento de software e autor de obras influentes como "Clean Code" e "Clean Architecture". Entre suas muitas contribuições para boas práticas de programação, Uncle Bob popularizou o acrônimo FIRST, que define cinco características essenciais para testes de software de qualidade.

O princípio FIRST estabelece que testes de unidade devem ser:

Fast (Rápidos)
Independent (Independentes)
Repeatable (Repetíveis)
Self-validating (Auto-validáveis)
Timely (Oportunos) / Thorough (Completos)

Nota: Existem duas interpretações comuns para o "T" em FIRST: "Timely" (Oportunos) e "Thorough" (Completos). Ambas são válidas e complementares no contexto de boas práticas de teste.

Vamos explorar cada um desses princípios em detalhes e ver exemplos práticos em Java de como aplicá-los.

Fast (Rápidos)

O que significa?

Testes devem ser rápidos para executar. Idealmente, centenas ou milhares de testes devem rodar em poucos segundos. Isso permite que os desenvolvedores executem os testes com frequência durante o desenvolvimento, o que é essencial para o ciclo de feedback rápido.

Por que é importante?

Testes lentos desencorajam os desenvolvedores de executá-los frequentemente. Se os testes demorarem muito tempo para executar, os desenvolvedores podem ser tentados a pular a etapa de testes, o que pode levar a bugs não detectados.

Exemplo em Java:

// Exemplo de teste rápido
public class CalculadoraTest {

    @Test
    public void testSoma() {
        Calculadora calc = new Calculadora();
        assertEquals(5, calc.soma(2, 3));
    }
}

Anti-exemplo:

// Teste lento - deve ser evitado
@Test
public void testOperacaoComBancoDeDados() {
    // Configuração de conexão com banco real
    Database db = new Database("jdbc:mysql://localhost:3306/banco");

    // Operações de leitura/escrita no banco
    // ...

    // Teste que depende de operações I/O lentas
}

Como corrigir:

Use mocks e stubs para simular dependências externas
Evite operações de I/O nos testes unitários (banco de dados, sistema de arquivos, rede)
Deixe testes mais complexos/lentos para testes de integração

Independent (Independentes)

O que significa?

Cada teste deve ser independente dos outros. Um teste não deve depender do estado deixado por outro teste, nem a ordem de execução deve importar.

Por que é importante?

Testes interdependentes são frágeis e difíceis de depurar. Se o teste A falhar, e o teste B depender dele, B também falhará, mesmo que a funcionalidade que B está testando esteja funcionando corretamente.

Exemplo em Java:

public class ContaBancariaTest {

    private ContaBancaria conta;

    @Before
    public void setUp() {
        // Cada teste começa com uma conta nova com 100 reais
        conta = new ContaBancaria(100.0);
    }

    @Test
    public void testSaque() {
        assertTrue(conta.sacar(50.0));
        assertEquals(50.0, conta.getSaldo(), 0.001);
    }

    @Test
    public void testSaqueMaiorQueSaldo() {
        assertFalse(conta.sacar(150.0));
        assertEquals(100.0, conta.getSaldo(), 0.001);
    }
}

Anti-exemplo:

public class ContaBancariaTestRuim {

    // Estado compartilhado entre testes - má prática
    private static ContaBancaria contaCompartilhada = new ContaBancaria(100.0);

    @Test
    public void test1_Saque() {
        assertTrue(contaCompartilhada.sacar(50.0));
        assertEquals(50.0, contaCompartilhada.getSaldo(), 0.001);
    }

    @Test
    public void test2_SaqueMaiorQueSaldo() {
        // Este teste vai falhar porque depende do estado deixado pelo teste anterior
        // O saldo agora é 50, não 100
        assertFalse(contaCompartilhada.sacar(150.0)); 
        assertEquals(50.0, contaCompartilhada.getSaldo(), 0.001);
    }
}

Como corrigir:

Use métodos @Before (JUnit 4) ou @BeforeEach (JUnit 5) para configurar um ambiente limpo antes de cada teste
Evite variáveis estáticas compartilhadas entre testes
Não nomeie testes com prefixos numéricos para forçar uma ordem de execução

Repeatable (Repetíveis)

O que significa?

Os testes devem produzir o mesmo resultado toda vez que forem executados, independentemente do ambiente ou timing. Eles devem funcionar em qualquer ambiente, seja no servidor de CI, no laptop de desenvolvimento ou na máquina de um colega.

Por que é importante?

Testes não repetíveis são imprevisíveis e podem levar a falsos positivos ou falsos negativos. Isso diminui a confiança nos testes e pode levar a bugs difíceis de rastrear.

Exemplo em Java:

public class GeradorDeRelatoriosTest {

    @Test
    public void testGeracaoRelatorio() {
        // Usando uma data fixa em vez da data atual
        LocalDate dataFixa = LocalDate.of(2023, 4, 10);

        GeradorDeRelatorios gerador = new GeradorDeRelatorios();
        String relatorio = gerador.gerarRelatorio(dataFixa);

        assertTrue(relatorio.contains("Relatório de 10/04/2023"));
    }
}

Anti-exemplo:

public class GeradorDeRelatoriosTestRuim {

    @Test
    public void testGeracaoRelatorio() {
        // Usando a data atual - o teste pode falhar no futuro
        GeradorDeRelatorios gerador = new GeradorDeRelatorios();
        String relatorio = gerador.gerarRelatorio(LocalDate.now());

        // Este assert pode falhar dependendo do dia em que o teste é executado
        assertTrue(relatorio.contains("Relatório de " + LocalDate.now().format(DateTimeFormatter.ofPattern("dd/MM/yyyy"))));
    }
}

Como corrigir:

Evite depender de dados variáveis como data/hora atual, valores aleatórios
Use injeção de dependência para controlar fontes de dados externos
Simule componentes externos que podem variar (APIs, banco de dados)
Use dados de teste fixos e predeterminados

Self-validating (Auto-validáveis)

O que significa?

Os testes devem determinar automaticamente se passaram ou falharam, sem necessidade de interpretação humana dos resultados. Eles devem produzir uma saída binária: passou ou falhou.

Por que é importante?

Testes que requerem interpretação manual são propensos a erros e consomem tempo. A automação completa permite que os testes sejam executados como parte de um processo de integração contínua.

Exemplo em Java:

public class ProcessadorDePagamentoTest {

    @Test
    public void testPagamentoComSucesso() {
        Cartao cartao = new Cartao("1234-5678-9012-3456", "12/2025", "123");
        ProcessadorDePagamento processador = new ProcessadorDePagamento();

        ResultadoPagamento resultado = processador.processar(cartao, 100.0);

        assertTrue(resultado.sucesso());
        assertEquals("Pagamento aprovado", resultado.mensagem());
    }
}

Anti-exemplo:

public class ProcessadorDePagamentoTestRuim {

    @Test
    public void testPagamentoComSucesso() {
        Cartao cartao = new Cartao("1234-5678-9012-3456", "12/2025", "123");
        ProcessadorDePagamento processador = new ProcessadorDePagamento();

        ResultadoPagamento resultado = processador.processar(cartao, 100.0);

        // Imprime resultado para interpretação manual - má prática
        System.out.println("Resultado do pagamento: " + resultado.mensagem());
        // Não há assertions para validar automaticamente
    }
}

Como corrigir:

Use sempre assertions para validar resultados
Não dependa de inspeção manual de logs ou output do console
Automatize completamente a verificação dos resultados esperados

Timely (Oportunos)

O que significa?

Os testes devem ser escritos no momento certo - idealmente antes do código de produção (TDD - Test-Driven Development) ou, pelo menos, ao mesmo tempo em que o código está sendo escrito.

Por que é importante?

Escrever testes após o código já estar pronto pode tornar o código mais difícil de testar, levando a design menos modular. Além disso, há o risco de o desenvolvedor focar apenas em caminhos felizes, ignorando casos de borda.

Exemplo em Java (TDD):

// 1. Primeiro, escrevemos o teste
@Test
public void testValidacaoEmail() {
    ValidadorEmail validador = new ValidadorEmail();
    assertTrue(validador.ehValido("usuario@exemplo.com"));
    assertFalse(validador.ehValido("usuario@"));
    assertFalse(validador.ehValido("usuario"));
    assertFalse(validador.ehValido("@exemplo.com"));
}

// 2. Depois, implementamos o código para passar no teste
public class ValidadorEmail {
    public boolean ehValido(String email) {
        if (email == null || email.isEmpty()) {
            return false;
        }

        // Verifica se contém @ e se não está no início ou fim
        int posicaoArroba = email.indexOf('@');
        if (posicaoArroba <= 0 || posicaoArroba == email.length() - 1) {
            return false;
        }

        // Verifica se há texto após o @ e se contém pelo menos um ponto
        String dominio = email.substring(posicaoArroba + 1);
        return dominio.contains(".") && !dominio.startsWith(".");
    }
}

Anti-exemplo:

// Implementação sem testes prévios
public class ValidadorEmailSemTestes {
    public boolean ehValido(String email) {
        return email != null && email.contains("@");
    }
}

// Testes escritos tardiamente, após a implementação estar "completa"
@Test
public void testValidacaoEmailTardio() {
    ValidadorEmailSemTestes validador = new ValidadorEmailSemTestes();
    assertTrue(validador.ehValido("usuario@exemplo.com"));

    // Ops, descobrimos que a implementação é muito simplista
    // e aceita emails claramente inválidos
    assertTrue(validador.ehValido("usuario@")); // Este deveria falhar!
}

Como corrigir:

Adote o TDD ou, pelo menos, escreva testes em paralelo com o código
Use testes para guiar o design do código
Considere testes como parte da implementação, não como uma tarefa adicional

Thorough (Completos)

O que significa?

Os testes devem ser completos e minuciosos, cobrindo não apenas os caminhos felizes, mas também os casos de borda, condições de erro e situações excepcionais que o código pode enfrentar.

Por que é importante?

Testes que cobrem apenas o cenário ideal podem deixar passar bugs em casos menos comuns, mas igualmente importantes. Uma cobertura abrangente garante que o código seja robusto em todas as situações possíveis.

Exemplo em Java:

public class ValidadorSenhaTest {

    private ValidadorSenha validador;

    @Before
    public void setUp() {
        validador = new ValidadorSenha();
    }

    // Casos felizes
    @Test
    public void testSenhaValida() {
        assertTrue(validador.validar("Abcd1234!"));
        assertTrue(validador.validar("P@ssw0rd123"));
    }

    // Casos de borda
    @Test
    public void testTamanhoMinimo() {
        assertFalse(validador.validar("Ab1!"));  // Muito curta
        assertTrue(validador.validar("Abcd1234!"));  // Mínimo exato
    }

    @Test
    public void testTamanhoMaximo() {
        assertTrue(validador.validar("Abcd1234!Abcd1234!"));  // Ok
        assertFalse(validador.validar("Abcd1234!Abcd1234!Abcd1234!Abcd1234!")); // Muito longa
    }

    // Casos de erro
    @Test
    public void testSenhaComCaracteresEspeciais() {
        assertTrue(validador.validar("Abcd1234!"));
        assertFalse(validador.validar("Abcd1234"));  // Sem caractere especial
    }

    @Test
    public void testSenhaComNumeros() {
        assertTrue(validador.validar("Abcd1234!"));
        assertFalse(validador.validar("Abcd!"));  // Sem números
    }

    @Test
    public void testSenhaComLetrasMaiusculas() {
        assertTrue(validador.validar("Abcd1234!"));
        assertFalse(validador.validar("abcd1234!"));  // Sem maiúsculas
    }

    @Test
    public void testSenhaComLetrasMinusculas() {
        assertTrue(validador.validar("Abcd1234!"));
        assertFalse(validador.validar("ABCD1234!"));  // Sem minúsculas
    }

    // Casos nulos ou inválidos
    @Test
    public void testSenhaNula() {
        assertFalse(validador.validar(null));
    }

    @Test
    public void testSenhaVazia() {
        assertFalse(validador.validar(""));
    }

    @Test
    public void testSenhaComEspacos() {
        assertFalse(validador.validar("Abcd 1234!"));
    }
}

Anti-exemplo:

public class ValidadorSenhaTestInsuficiente {

    @Test
    public void testSenhaValida() {
        ValidadorSenha validador = new ValidadorSenha();
        // Testa apenas o caminho feliz, ignorando todos os casos de borda e erros
        assertTrue(validador.validar("Abcd1234!"));
    }
}

Como aplicar:

Identifique todos os requisitos e restrições da funcionalidade
Teste os casos felizes, casos de borda e condições de erro
Use técnicas como análise de valores limite e particionamento de equivalência
Considere usar ferramentas de cobertura de código para identificar caminhos não testados
Inclua testes para entradas nulas, vazias ou inválidas
Verifique comportamentos com valores mínimos, máximos e fora dos limites

Aplicação Prática: Exemplo Completo

Vamos criar um exemplo completo aplicando todos os princípios FIRST (incluindo ambas as interpretações do "T") para uma classe CalculadoraDeJuros:

// Classe de produção
public class CalculadoraDeJuros {
    private final RepositorioTaxas repositorio;

    public CalculadoraDeJuros(RepositorioTaxas repositorio) {
        this.repositorio = repositorio;
    }

    public double calcularJurosCompostos(double principal, int anos, String tipoDeConta) {
        double taxa = repositorio.obterTaxaAnual(tipoDeConta);

        if (taxa <= 0) {
            throw new IllegalArgumentException("Taxa de juros deve ser positiva");
        }

        return principal * Math.pow(1 + taxa, anos);
    }
}

// Interface do repositório
public interface RepositorioTaxas {
    double obterTaxaAnual(String tipoDeConta);
}

Agora, vamos criar testes que seguem o princípio FIRST:

// Importações para JUnit 5
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.DisplayName;
import static org.junit.jupiter.api.Assertions.*;
import static org.mockito.Mockito.*;

public class CalculadoraDeJurosTest {

    // Mock do repositório para tornar o teste Fast e Repeatable
    private RepositorioTaxas mockRepositorio;
    private CalculadoraDeJuros calculadora;

    @BeforeEach // JUnit 5 usa @BeforeEach em vez de @Before do JUnit 4
    void setUp() {
        // Setup para cada teste - torna os testes Independent
        mockRepositorio = mock(RepositorioTaxas.class);
        calculadora = new CalculadoraDeJuros(mockRepositorio);
    }

    @Test
    @DisplayName("Deve calcular juros compostos corretamente") // Anotação descritiva do JUnit 5
    void testCalculoJurosCompostos() {
        // Arrange
        when(mockRepositorio.obterTaxaAnual("poupanca")).thenReturn(0.05); // 5%

        // Act
        double resultado = calculadora.calcularJurosCompostos(1000.0, 3, "poupanca");

        // Assert - torna o teste Self-validating
        assertEquals(1157.625, resultado, 0.001);
    }

    @Test
    @DisplayName("Deve calcular juros para diferentes tipos de contas")
    void testCalculoJurosCompostosParaDiferentesTiposDeContas() {
        // Arrange
        when(mockRepositorio.obterTaxaAnual("poupanca")).thenReturn(0.05); // 5%
        when(mockRepositorio.obterTaxaAnual("investimento")).thenReturn(0.08); // 8%

        // Act & Assert
        assertEquals(1157.625, calculadora.calcularJurosCompostos(1000.0, 3, "poupanca"), 0.001);
        assertEquals(1259.712, calculadora.calcularJurosCompostos(1000.0, 3, "investimento"), 0.001);
    }

    @Test
    @DisplayName("Deve lançar exceção para taxa negativa")
    void testExcecaoParaTaxaNegativa() {
        // Arrange
        when(mockRepositorio.obterTaxaAnual("invalida")).thenReturn(-0.01);

        // Act & Assert - JUnit 5 usa assertThrows em vez de expected
        assertThrows(IllegalArgumentException.class, () -> {
            calculadora.calcularJurosCompostos(1000.0, 3, "invalida");
        });
    }
}

Este exemplo ilustra os princípios FIRST:

Fast: Os testes não dependem de recursos externos lentos, usando mocks para o repositório.
Independent: Cada teste tem seu próprio setup e não depende de estado compartilhado.
Repeatable: Os resultados dos testes serão os mesmos independentemente de onde ou quando forem executados, pois usamos dados mock fixos.
Self-validating: Cada teste contém assertions claras que determinam automaticamente o sucesso ou falha.
T (Timely/Thorough): → Timely: Os testes foram escritos para guiar o design da classe, garantindo que ela seja testável desde o início. → Thorough: Os testes cobrem tanto o comportamento normal (cálculo de juros correto) quanto condições de erro (taxas negativas).

Conclusão

O princípio FIRST fornece um guia valioso para escrever testes de unidade eficazes. Adotar essas práticas leva a:

Testes mais confiáveis e robustos
Ciclos de feedback mais rápidos durante o desenvolvimento
Código mais limpo e com melhor design
Maior confiança nas mudanças e refatorações
Documentação viva do comportamento esperado do sistema

Ao seguir esses princípios consistentemente, as equipes de desenvolvimento podem criar uma suíte de testes que realmente agrega valor ao projeto, em vez de se tornar um fardo de manutenção. Lembre-se de que testes bem escritos são um investimento que paga dividendos ao longo da vida útil do software.