História dos Design Patterns

Christopher Alexander e A Pattern Language

Em 1977, Alexander publicou o livro A Pattern Language, escrito em parceria com Sara Ishikawa e Murray Silverstein. A obra descreve 253 padrões recorrentes usados na construção de cidades, edifícios e detalhes construtivos.

Além disso, os padrões do livro se conectam entre si, formando uma rede de referências cruzadas. Os autores, inclusive, tratavam cada padrão como uma hipótese, sujeita a revisão conforme a observação do mundo real.

A proposta era simples e poderosa:

Certos problemas de design aparecem repetidamente, e boas soluções para esses problemas podem ser documentadas, nomeadas e reutilizadas.

Pouco depois, Alexander também publicou The Timeless Way of Building, que aprofunda a filosofia por trás da linguagem de padrões. Juntos, os dois livros formam a base conceitual de tudo o que veio depois.

O método também saiu do papel. Em The Oregon Experiment, Alexander relatou como a Universidade do Oregon adotou essa abordagem como base do seu planejamento, o que mostra que a história dos design patterns nasceu de uma prática real.

A estrutura de um padrão

Cada padrão de Alexander apresenta um problema e, em seguida, oferece uma solução. Dessa forma, qualquer pessoa consegue adaptar a orientação às suas próprias condições.

Na prática, cada padrão descrevia três elementos principais:

• Problema recorrente: a situação que aparece repetidamente em projetos diferentes.
• Contexto: as condições em que esse problema surge.
• Solução testada: uma resposta comprovada, que pode ser adaptada a cada caso.

Essa estrutura simples, com nome, problema, contexto e solução, atravessou décadas. De fato, ela aparece quase intacta nos catálogos de software que surgiriam mais tarde.

Por isso, quem estuda a história dos design patterns percebe que a grande contribuição de Alexander foi o formato, e não um padrão específico. Afinal, foi esse formato que os programadores copiaram.

Beck e Cunningham, um marco na história dos design patterns

Em 1987, Kent Beck e Ward Cunningham apresentaram na conferência OOPSLA o trabalho Using Pattern Languages for Object-Oriented Programs. Nele, os dois adaptaram a linguagem de padrões de Alexander para o projeto de interfaces em Smalltalk.

O artigo descreve cinco padrões iniciais, como Window Per Task e Few Panes Per Window. Segundo os autores, uma equipe de especialistas sem domínio profundo de Smalltalk conseguiu especificar interfaces razoáveis após apenas um dia de prática.

Esse resultado mostrou que padrões podiam transferir conhecimento de design entre pessoas. Assim, a história dos design patterns ganhou seu primeiro capítulo dentro da computação.

Curiosamente, a influência de Alexander não parou nos padrões. Afinal, Ward Cunningham também se inspirou nas ideias dele ao criar o WikiWikiWeb, o primeiro wiki da história.

Os desafios da orientação a objetos

Com a popularização da orientação a objetos, algumas perguntas apareciam em quase todos os projetos. Por exemplo:

• Como reduzir o acoplamento entre as classes?
• De que forma organizar as responsabilidades?
• O que fazer para criar sistemas extensíveis?
• Qual a melhor maneira de lidar com mudanças constantes?

Os desenvolvedores perceberam que muitos desses problemas se repetiam e que as soluções também se repetiam. Foi nesse contexto que quatro autores decidiram catalogar essas soluções de forma sistemática.

Essa vontade de catalogar é o ponto central da história dos design patterns no software. Em outras palavras, a experiência individual passou a virar conhecimento compartilhado e com nome próprio.

Os 23 padrões e suas categorias

O livro organizou 23 padrões de projeto, divididos em três categorias. Cada categoria responde a um tipo diferente de problema:

• Criacionais (5): Abstract Factory, Builder, Factory Method, Prototype e Singleton.
• Estruturais (7): Adapter, Bridge, Composite, Decorator, Facade, Flyweight e Proxy.
• Comportamentais (11): Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method e Visitor.

Os padrões criacionais tratam da criação de objetos. Por outro lado, os estruturais cuidam da composição entre classes e objetos, enquanto os comportamentais organizam a comunicação e a divisão de responsabilidades.

Alguns nomes do catálogo ficaram tão conhecidos que viraram vocabulário comum entre desenvolvedores. O Singleton, por exemplo, garante uma única instância de uma classe e oferece um ponto global de acesso a ela.

Já o Strategy encapsula algoritmos intercambiáveis, para que o código escolha o comportamento em tempo de execução. Por sua vez, o Observer permite que vários objetos recebam notificações quando o estado de outro objeto muda.

Esse vocabulário compartilhado talvez seja a contribuição mais prática do catálogo. Afinal, quando alguém diz "aqui cabe um Adapter", todo o time entende a intenção sem precisar desenhar a solução inteira.

Além do catálogo, o livro destacou dois princípios que influenciam o design até hoje. O primeiro é programar para uma interface, e não para uma implementação, e o segundo é preferir composição de objetos a herança de classes.

Como o livro documenta cada padrão

Mais do que listar soluções, o livro explicou quando usar cada padrão, quais problemas ele resolve e quais consequências ele traz. Para isso, a GoF adotou um formato padronizado de documentação.

Esse formato inclui seções como intenção, motivação, aplicabilidade, estrutura, participantes, colaborações, consequências, implementação, código de exemplo, usos conhecidos e padrões relacionados. Em outras palavras, cada padrão vinha com contexto suficiente para uma decisão consciente.

Esse material se tornou um marco na engenharia de software. Com isso, ele ajudou a consolidar o design orientado a objetos como disciplina.

No mesmo ano de 1994, aconteceu a primeira conferência PLoP (Pattern Languages of Programs), organizada pelo Hillside Group. A partir dela, a comunidade passou a publicar e revisar novos padrões de forma contínua.

Padrões embutidos no .NET

O .NET é um bom exemplo dessa evolução. Segundo a documentação oficial, a plataforma aplica o padrão Observer por meio das interfaces genéricas IObservable e IObserver.

Além disso, a mesma documentação recomenda os eventos padrão do .NET para notificações simples dentro de uma única aplicação. Ou seja, a linguagem já oferece um atalho para um dos padrões mais famosos da GoF.

// Observer com eventos nativos do C#
public sealed class OrderService
{
    public event EventHandler<OrderPlacedEventArgs>? OrderPlaced;

    public void PlaceOrder(Guid orderId)
    {
        // Regra de negócio omitida para simplificar o exemplo
        OrderPlaced?.Invoke(this, new OrderPlacedEventArgs(orderId));
    }
}

public sealed class OrderPlacedEventArgs(Guid orderId) : EventArgs
{
    public Guid OrderId { get; } = orderId;
}

// Assinante reagindo à notificação
var service = new OrderService();
service.OrderPlaced += (_, args) => Console.WriteLine($"Order {args.OrderId} placed");
service.PlaceOrder(Guid.NewGuid());

Do mesmo modo, o container de injeção de dependência do .NET assume a responsabilidade de criar e entregar objetos. Assim, você não precisa escrever factories manualmente para cada serviço da aplicação.

Com o tempo, os desenvolvedores perceberam que não era necessário implementar padrões "na unha" o tempo todo. Afinal, muitos deles já estavam embutidos nas plataformas.

Esse movimento é uma consequência natural da história dos design patterns. Quanto mais um padrão se repete, maior a chance de alguém transformá-lo em recurso da linguagem ou do framework.

As críticas na história dos design patterns

A história dos design patterns também tem seus críticos. O mais citado é Peter Norvig, que demonstrou que 16 dos 23 padrões da GoF ficam mais simples ou até desaparecem em linguagens como Lisp e Dylan.

Para muitos, esse argumento sugere que alguns padrões compensam limitações da linguagem, e não problemas universais de design. Portanto, o valor de um padrão depende muito da ferramenta que você usa.

Ainda assim, a crítica não apaga a importância da história dos design patterns. Na verdade, ela reforça a ideia original de Alexander, segundo a qual cada padrão é uma hipótese que precisa de validação no contexto real.

Padrões nas arquiteturas modernas

Arquiteturas modernas, como Clean Architecture, Hexagonal Architecture e DDD, absorveram e reinterpretaram muitos padrões da GoF. Nesse processo, elas passaram a aplicá-los de forma mais contextualizada.

Além disso, linguagens modernas como o C# reduzem a verbosidade de muitos padrões por meio de recursos de linguagem, expressões funcionais e abstrações nativas.

Um delegate, por exemplo, pode substituir uma hierarquia inteira de classes do padrão Strategy. Da mesma forma, uma expressão lambda torna desnecessárias muitas classes auxiliares que o padrão Command exigia.