A Evolução dos Padrões de Criação na Engenharia de Software

A engenharia de software passou por uma evolução significativa ao longo dos anos, impulsionada pelo aprendizado contínuo com erros e acertos. Curiosamente, os maiores desafios nem sempre foram “bugs” explícitos no código, mas sim code smells: aquelas práticas sutis que resultam em código acoplado, visualmente poluído e de difícil manutenção — problemas que só se revelam completamente quando você precisa modificar o sistema.

O Problema da Herança Profunda e o Acoplamento Rígido

A arquitetura de software moderna prioriza a manutenibilidade sustentável e a orquestração organizada de módulos. Nesse contexto, a Programação Orientada a Objetos enfrentou historicamente o problema da herança multinível. Estruturas de herança muito profundas geram alto acoplamento, criando um cenário onde a alteração em uma classe base (pai) pode invalidar ou quebrar o comportamento de todas as classes derivadas, tornando o sistema frágil — como um castelo de cartas onde tocar a base desmorona toda a estrutura.

Outro ponto crítico que merece destaque foi o uso indiscriminado do operador new, que se tornou um dos principais vetores de acoplamento rígido em sistemas corporativos. Nas décadas de 1990 e 2000, desenvolvedores perceberam na prática que espalhar a lógica de instanciação por todo o código tornava os testes unitários quase impossíveis e a refatoração um verdadeiro pesadelo. Imagine: se uma classe mudasse seu construtor — adicionando um parâmetro ou alterando sua ordem — dezenas ou até centenas de classes clientes quebravam simultaneamente. Era necessário caçar cada ocorrência de new MinhaClasse() espalhada pelo código.

Historicamente, a modelagem excessivamente baseada em taxonomia (relação is-a) resultava em objetos inchados, obrigados a implementar interfaces ou herdar métodos irrelevantes ao seu contexto específico. Em contrapartida, a arquitetura moderna favorece a composição (relação has-a). Linguagens contemporâneas, como Go e Rust, exemplificam essa mudança de paradigma ao priorizar a composição de estruturas (structs) em detrimento da herança de classes clássica — mostrando que a indústria aprendeu com seus erros.

Design Patterns (1994)

O livro do “Gang of Four” (Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides) revolucionou a engenharia de software ao catalogar sistematicamente 23 padrões de projeto, divididos em três categorias: criacionais, estruturais e comportamentais. Os cinco padrões criacionais — Singleton, Factory Method, Abstract Factory, Builder e Prototype — não eram invenções do zero, mas sim a formalização de práticas que programadores experientes já vinham utilizando de forma intuitiva. O grande mérito do GoF foi criar uma linguagem comum: quando um desenvolvedor mencionava “Factory”, todos sabiam exatamente do que se tratava.

A Transformação na Aplicação dos Padrões

No entanto, a forma como aplicamos esses padrões mudou drasticamente. Antigamente, no final dos anos 1990 e início dos 2000, equipes escreviam manualmente classes Factory verbosas para praticamente tudo, muitas vezes gerando código boilerplate excessivo. Era comum ver projetos com dezenas de classes cuja única responsabilidade era instanciar outros objetos.

Hoje, a evolução dos frameworks absorveu grande parte dessa responsabilidade, transformando padrões de projeto em features de infraestrutura. Spring, por exemplo, é essencialmente um gigantesco container de Injeção de Dependência que implementa Abstract Factory e Singleton de forma transparente. Você não escreve mais factories manualmente — você anota classes com @Component e deixa o framework gerenciar todo o ciclo de vida.

Por Que a Composição Exige Padrões Criacionais

Quando o design favorece a composição, o uso de Padrões de Criação (Creational Patterns) torna-se não apenas útil, mas essencial. Adotar a composição significa que seus objetos são construídos combinando outros objetos menores, e essa montagem pode ser complexa. Os Padrões de Criação permitem abstrair todo esse processo de construção, promovendo o desacoplamento.

Ao programar voltado para interfaces (contratos) em vez de implementações concretas, você garante flexibilidade e testabilidade. O código cliente só sabe o que o objeto faz, não como ele foi construído — encapsulando toda a complexidade da criação. É a diferença entre dizer “me dê um carro” versus “me dê um Toyota Corolla 2024 azul com motor 2.0 e câmbio automático”.

O Estado Atual: Sofisticação, Não Abandono

Em suma, a engenharia de software moderna não abandonou a criação de objetos, mas a sofisticou. Movemos a complexidade da instanciação para três lugares distintos:

1. Frameworks (via Injeção de Dependência): Spring, CDI, Guice assumem a responsabilidade de construir e gerenciar objetos
2. Bibliotecas de geração de código: Lombok, AutoValue, Immutables geram automaticamente builders e factories em tempo de compilação
3. Métodos estáticos expressivos: Factory methods nomeados como Usuario.criarAdmin() ou Relatorio.vazio() que comunicam intenção

O objetivo final permanece o mesmo que o Gang of Four defendeu há três décadas: garantir que o código que usa o objeto não precise saber como ele foi montado. A diferença é que hoje temos ferramentas mais poderosas para alcançar esse objetivo, mas os princípios fundamentais — desacoplamento, abstração, responsabilidade única — continuam sendo a bússola que guia boas decisões de design.

---

Considerações e Consequências no Código

Vantagens dos Padrões Criacionais:

• Testabilidade: Mocks e stubs podem ser facilmente injetados no lugar de implementações reais
• Flexibilidade: Trocar implementações sem modificar código cliente (Open/Closed Principle)
• Manutenibilidade: Mudanças na construção ficam isoladas em um único lugar
• Clareza de Intenção: Métodos factory com nomes expressivos documentam o código

Desvantagens e Cuidados:

• Complexidade Inicial: Pode parecer “over-engineering” para projetos pequenos
• Curva de Aprendizado: Desenvolvedores juniores podem achar abstrato demais
• Performance: Camadas adicionais de abstração têm custo (geralmente negligenciável)
• Excesso de Abstração: O antipadrão “Inner-platform effect” — criar um sistema tão genérico que se torna complexo demais

A Regra de Ouro:

Use padrões criacionais quando a dor do acoplamento superar a dor da abstração. Se você está constantemente quebrando testes ao mudar construtores, ou se não consegue testar uma classe sem instanciar metade do sistema, chegou a hora de abstrair a criação.