Neste artigo
Quem já se perdeu num código cheio de if e else e pensou “tem que existir um jeito melhor” já esbarrou no problema que os Design Patterns (padrões de projeto) tentam resolver. Eles são soluções documentadas para problemas que se repetem no desenvolvimento de software.
De onde vêm
Os padrões mais conhecidos foram catalogados no livro “Design Patterns: Elements of Reusable Object-Oriented Software” (Addison-Wesley, 1994), de Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, o grupo conhecido como Gang of Four. O livro reúne 23 padrões em três grupos: 5 criacionais, 7 estruturais e 11 comportamentais.
O site Refactoring Guru é uma referência gratuita com exemplos em várias linguagens. Ele lista 22 padrões clássicos (5 criacionais, 7 estruturais e 10 comportamentais), então não cobre todos os 23 do livro.
O que são, e o que não são
Não são bibliotecas para instalar nem regras fixas. São modelos de solução que você adapta ao seu contexto, e também um vocabulário comum: dizer “usei um Strategy” comunica a intenção sem ler a implementação.
Sinais de que um padrão pode ajudar
- você repete a mesma solução em vários lugares do código;
- o sistema cresceu e virou espaguete, difícil de mudar sem quebrar outras partes;
- uma alteração em um arquivo quebra outros cinco, sinal de acoplamento excessivo;
- você quer adicionar funções com o mínimo de impacto no que existe.
Nem todo código precisa de um padrão. Aplicar um sem necessidade só adiciona complexidade.
Três exemplos
Singleton garante uma única instância de uma classe. Serve para algo como o pool de conexões com o banco, que você reaproveita em vez de abrir uma conexão nova a cada requisição. É também o padrão mais criticado, porque cria estado global e dificulta testes.
Observer deixa vários objetos reagirem às mudanças de outro. Em um sistema de pedidos, quando o status passa de “processando” para “enviado”, quem precisa saber (notificação ao cliente, painel) é avisado sem que o código do pedido dependa diretamente deles.
Factory centraliza a criação de objetos de tipos diferentes. Num sistema de pagamento com cartão, boleto e Pix, uma fábrica escolhe a classe certa, e o resto do código não precisa conhecer os detalhes de cada meio.
Perguntas comuns
Servem só para orientação a objetos? Os 23 do livro foram descritos nesse contexto, mas a ideia de nomear e reaplicar soluções conhecidas aparece também em linguagens funcionais e multiparadigma, às vezes com nomes ou formas diferentes.
Qual a diferença para um framework? Um framework é código pronto que você importa. Um padrão é uma forma de organizar o seu próprio código.
Preciso decorar os 23? Não. O mais útil é reconhecer o problema e saber que existe uma solução catalogada. Uma forma de estudar é pegar um problema real do seu código, descobrir a categoria dele (criacional, estrutural ou comportamental) e procurar o padrão correspondente antes de aplicar.
Para o mesmo raciocínio em escala de sistema, e não de classe, veja os textos sobre arquitetura do blog.
Leia também: O mesmo critério que uso para padrões, escolher pelo problema e não pela moda, vale para a decisão de framework front-end.
