Minha conclusão ao conhecer os “Design Patterns” [PT-BR]

Introdução

Terminei de conhecer os famosos “Design Patterns”, descritos originalmente no livro “Design Patterns: Elements of Reusable Object-Oriented Software”, lançado em 1994 pelo “Gang of Four” (GoF), que é, de longe, um dos maiores clássicos da área da computação. Organizei com meus colegas um clube do livro para ler uma versão mais acessível, prática e modernizada desse livro, que faz mais sentido para um clube. Trata-se do “Dive Into DESIGN PATTERNS”, do famoso site Refactoring.Guru.

Minha reflexão

Depois de conhecer todos os 22 design patterns, comecei a perceber como eles influenciaram o mundo do desenvolvimento em que vivo hoje. Seja em livros, publicações, artigos, palestras, bibliotecas, frameworks ou até no design de linguagens mais modernas, eu vejo que os design patterns estão, digamos, no inconsciente coletivo. Mesmo que eu não os use diretamente, já estou recebendo influências deles de alguma forma.

Eu percebo que os design patterns não são ciência de foguetes; não são tão avançados que eu nunca poderia criá-los sozinho. Na verdade, são soluções para problemas comuns no desenvolvimento que muitas pessoas usaram repetidamente e decidiram catalogar em um livro, dando-lhes nomes para facilitar a comunicação dessas soluções entre desenvolvedores.

Eles não são um conjunto de regras fixas nem “as melhores soluções” absolutas. Tanto é que muitos dos patterns têm anti-patterns associados, cada um com seus prós e contras. Quando eu uso muitos desses patterns em um projeto simples, isso pode levar a um excesso de complexidade desnecessária.

Eu vejo que o software está em constante mudança, e a ideia é identificar problemas comuns, distinguir partes que geralmente não mudam daquelas que podem mudar constantemente nas regras de negócio, e aplicar um pattern que facilite a manutenção. Isso melhora a comunicação entre desenvolvedores e evita a reinvenção da roda, utilizando boas soluções já existentes.

Ler sobre todos os patterns é também um exercício para eu entender como bons desenvolvedores pensam e resolvem problemas. Ao terminar o livro, começo a pensar de maneira mais estruturada, como se eu tivesse na mente várias soluções possíveis para um problema, com base no repertório que adquiri ao conhecer cada um deles, o que melhora a qualidade, legibilidade e manutenibilidade do meu código. Isso me permite me apoiar nos ombros de gigantes e passar a adotar uma forma de pensamento semelhante à deles.

Exemplos práticos

No .NET, que é o framework que utilizo no meu trabalho há muitos anos, encontrei várias implementações de Design Patterns. Organizando por ordem de listagem, o Factory Method e o Abstract Factory podem ser encontrados no DbProviderFactory do ADO.NET. O StringBuilder é um exemplo do padrão Builder, enquanto a interface ICloneable implementa o padrão Prototype. O HttpContext.Current do ASP.NET é uma implementação clássica do padrão Singleton.

O padrão Adapter pode ser visto em IEnumerable, e o System.Drawing abstrai a implementação gráfica utilizando o padrão Bridge. No Windows Forms, a classe Control aplica o padrão Composite (Object Tree), permitindo uma estrutura hierárquica de controles. O padrão Decorator é implementado nas várias classes derivadas de Stream, enquanto o WebClient serve como uma Facade simplificada para operações HTTP.

A classe String utiliza o padrão Flyweight (Cache) para otimizar o uso de memória, e o WebProxy é uma implementação de Proxy, controlando o acesso a serviços de rede. No ASP.NET, os Middlewares seguem o padrão Chain of Responsibility (Chain of Command). No WPF, a interface ICommand representa o padrão Command, enquanto System.Collections.IEnumerator é uma implementação do padrão Iterator.

O padrão Mediator é exemplificado pela classe Page no ASP.NET, que coordena a interação entre os controles de uma página. Controles como Forms.TextBox utilizam o padrão Memento (Snapshot) para permitir operações de desfazer/refazer. O padrão Observer é bem representado por System.EventHandler, facilitando a notificação de eventos. O padrão State é usado em Threading.Thread através do ThreadState, e o namespace System.Security.Cryptography permite a escolha de diferentes algoritmos, como MD5, SHA1, e SHA256, aplicando o padrão Strategy.

O método Control.Render no ASP.NET segue o padrão Template Method, definindo uma estrutura para a renderização de controles. Por fim, Xml.XmlDocument implementa o padrão Visitor, permitindo a execução de operações em uma estrutura de documento XML sem modificar as classes dos elementos.

Eu poderia continuar com outros exemplos, pois isso é aplicável a diversos frameworks e bibliotecas, tanto de front-end quanto de back-end, e até mesmo a outros paradigmas, como o funcional. Muitas vezes, utilizamos padrões de design no cotidiano sem estarmos cientes de seus nomes ou de como funcionam detalhadamente.

Conclusão

Meu post é mais otimista em relação ao livro porque, mesmo para criticar ou expressar uma opinião na mesa de desenvolvedores da sua empresa, é essencial lê-lo. Mesmo que você o considere sem valor ou uma total perda de tempo, o fato de ser um clássico extremamente influente já justifica a leitura.

O maior aprendizado para mim é que, mesmo que eu não use os design patterns diretamente, quem construiu o framework que utilizo os usou em várias partes dele. Como é o caso dos exemplos do .NET que dei. O mesmo vale para quem desenvolveu a linguagem que eu uso, mesmo que seja de um paradigma diferente da orientação a objetos. Eu recomendo pesquisar sobre isso se tiver interesse, pois há muitos exemplos, mas não quero me alongar. Se você deseja ir além do superficial como desenvolvedor de software e entender o porquê de cada coisa, por que esse framework funciona de determinada maneira e não de outra, e como escrever software de forma a facilitar sua vida e a de todos, estudar os design patterns é essencial.

Criei um repositório no GitHub com exemplos práticos de todos os “Design Patterns” em C#. Você pode conferir em Design Patterns em C# [PT-BR] – Github