Descomplicando os Padrões de Projetos (Design Patterns)

Atualizado pela última vez em 31 de janeiro de 2024

O conhecimento sobre os Padrões de Projetos ( Design Patterns), se tornaram essenciais para todo programador que quer alavancar sua carreira e conseguir as melhores vagas no mercado de trabalho. Porém, simplesmente decorá-los não é suficiente. Você precisa entender bem sua origem e porque utilizá-los. 

Porque é tão importante conhecer sobre Padrões de projetos?

Na nossa jornada como programadores, vamos nos deparar com algumas situações ou problemas que normalmente alguém já passou anteriormente. Desta forma, se alguém já passou por uma situação similar e tiver um “modelo  padrão” de como ele resolveu o seu problema, pode ser que esse “modelo”, consigamos utilizar e resolver também o nosso problema.  Esta é o ponto principal que os padrões de projetos nos fornecem.

O que temos hoje sobre o tema que envolve os padrões de projetos, foi consolidado decorrente dos estudos do Christopher Alexander, que em 1977 publicou um catálogo com mais de 253 padrões para arquitetura civil, o livro A Pattern Language: Towns – Buildings – Construction (Uma Linguagem de Padrões), sendo um marco para os estudos voltados para arquitetura de sistemas com uso dos patterns.

Um ponto interessante sobre o Christopher Alexander é que ele além de ser arquiteto, era matemático e urbanista. Sua dedicação primordial estava na pesquisa sobre o modo de projetar e construir, usando recursos sistêmicos, matemáticos, empíricos e participativos, com a intenção de moldar padrões que unisse tudo isso como uma tarefa científica mesmo.

Em 1964 ele publicou a obra Notes on the Synthesis of Form (Ensaio sobre a Síntese da Forma). Alexander descreve os elementos fundamentais do design em termos de forma e contexto. “A forma é a solução para o problema; o contexto define o problema”. Em outras palavras, dentro do processo do projeto, em uma perspectiva sistêmica,  a forma deveria satisfazer os requisitos do contexto em que se insere.

Em 1979 ele também publicou o livro The Timeless Way of Building, que, além de exemplificar, descreve seu método para a documentação de padrões. A sistematização com que ele organizou a sua ideia, chamou bastante a atenção dos arquitetos de software que consolidaram os seus conceitos aplicados às soluções sistêmicas. Demorou um pouco para a sua adoção, que veio só por volta de 1987, na OOPSLA, conferência sobre programação orientada a objetos. 

Nesta conferência, no Workshop sobre Especificação e Projeto para Programação Orientada a Objetos, Kent Beck e Ward Cunningham.  falaram sobre uma linguagem de padrões para projetar janelas em Smalltalk.  Muitos outros artigos surgiram na sequência, mas sua popularização só começou a acontecer por volta de 1993 com Erich Gamma, John Vlissides, Ralph Johnson, e Richard Helm que  introduziram os primeiros 23 padrões de projetos que foram publicados em 1994 no livro Design Patterns: Elements of Reusable Object-Oriented Software. (Padrões de Projeto – Soluções Reutilizáveis de Software Orientado a Objetos). Livro muito famoso até nos dias atuais. Como você pode perceber, o título do livro ficou bem longo, então ele ficou popularmente conhecido como “Livro GOF” (Gang of Four ou Gangue dos Quatro).

A “Gang of Four” apresentou vinte e três padrões de projeto de software e os dividiu em três categorias, cada uma com um determinado objetivo, são elas: criacional, estrutural e comportamental (GAMMA, HELM, et al., 2000). 

• Creational: São os padrões de criação que visam abstrair o processo de criação de objetos, ou seja, sua instanciação.
• Structural: São os padrões estruturais que tratam das associações entre classes e objetos, identificando qual é a melhor maneira de realizar o relacionamento entre as entidades.
• Behavioral: São os padrões comportamentais que tratam das interações e divisões de responsabilidades entre as classes ou objetos, facilitando a comunicação entre os objetos.

Com a tabela a seguir, você terá uma noção mais prática da importância desta categorização. A classificação geral dos 23 padrões de projetos do livro GOF estão separados por nível de classe e objeto relacionado com a sua respectiva categoria:

		CRIAÇÃO	ESTRUTURA	COMPORTAMENTO
ESCOPO	CLASSE	– Factory Method	– Class Adapter	– Interpreter – Template Method
	OBJETO	– Abstract Factory – Builder – Prototype – Singleton	– Object Adapter – Bridge – Composite – Decorator – Façade – Flyweight – Proxy	– Chain of Responsibility – Command – Interator – Mediator – Mememento – Observer – State – Strategy – Visitor

Fiz um resumo completo destes padrões e organizei em outro artigo “Resumo dos Padrões de Projetos (Design Patterns)“ que você pode utilizar como base para consulta, caso esqueça o uso de determinado padrão.

Como os padrões de projetos podem nos ajudar?

Um padrão descreve uma solução para um problema que ocorre com frequência. Os problemas, em alguns casos, são muitos parecidos, só mudam o contexto na qual estão inseridos.Mas a forma como é solucionado pode ser comum a outro problema distinto.

Projetistas familiarizados com certos padrões podem aplicá-los imediatamente a problemas de projeto, sem ter que redescobri-los

[Gamma 95].

Cada padrão de projeto observa um problema específico ou tópico particular de projeto orientado a objeto que necessita ser resolvido. Ele descreve em que situação deve ser aplicado, para que tipo de problema resolver, especifica também as consequências, custos e benefícios de sua utilização . 

(GAMMA, HELM, et al., 2000)

Além dos padrões serem um conjunto de ferramentas para soluções de problemas comuns em design de software. Eles definem uma linguagem comum que ajuda as equipes de desenvolvimento a se comunicarem com mais eficiência.

Como  é definido os padrões de projetos?

Repetindo, de acordo com o livro GOF,  basicamente temos três categorias de padrões (criacional, estrutural e comportamental). Obviamente cada categoria tem uma abordagem voltada para a finalidade da resolução do problema proposto. Além das categorias, é necessário a identificação de alguns elementos que definem cada padrão. Os principais elementos são:

• Nome: fornece uma maneira de descrever um problema, suas soluções.
• Problema que soluciona: descreve quando utilizar o padrão;
• Solução do problema: descreve os elementos do design, suas relações, responsabilidades e colaborações;
• Consequências / forças: são os resultados da aplicação do padrão escolhido. Custo, benefícios e impacto ao se aplicar o padrão no sistema

A ideia de padrões de projetos vai muito além do nível de classe e objeto. Hoje temos diversos outros padrões de projetos voltados para, por exemplo, a parte mais arquitetural. O mais famoso é o MVC (Model View Controller), além do MVVM que se popularizou com frameworks com Angular. Veja a seguir uma pequena lista dos principais:

• Interceptor
• Model View Controller (MVC)
• Model View ViewModel (MVVM)
• Model View Presenter (MVP)
• N-tier
• Specification
• Publish–subscribe
• Inversion of control

Dependendo do contexto do software que você está desenvolvendo, outros padrões são comumente utilizados para garantir uma alta qualidade no código. Além da refatoração, que é uma prática tão importante na garantia de evolução e manutenção, temos testes e aspectos de qualidade de desempenho. Veja a seguir outros padrões que são muitos utilizados:

• Rules Design Patterns
• Dependency Injection
• Intercepting filter
• Lazy loading
• Mock object
• Method chaining
• Inversion of control
• Unit of Work

Os padrões de projetos estão intimamente ligados à qualidade do design do software. Neste aspecto, resumidamente o foco principal é buscar a uma alta coesão e baixo acoplamento em nossos softwares, além de conseguirmos fazer uso maciço de reuso de códigos. 

Tenha em mente que a maioria dos padrões foram criados por profissionais altamente experientes, o que apesar de ser uma coisa muito benéfica, na maioria dos casos, o código-fonte pode se tornar maior e mais complexo em nossos projetos. É necessário conhecer muito bem os padrões e usufruir positivamente dos seus benefícios. Tenho convicção que os benefícios compensam o esforço em aprendê-los e sobretudo em aplicá-los.

Espero que você tenha aproveitado este artigo e se gostou, compartilhe. Quando você compartilha conhecimento e ajuda outras pessoas, uma rede de network se forma. Pode ter certeza que a pessoa que lê os artigos que você compartilhar, vai lembrar de sua boa ação. Então, não tenha receio, compartilhe!

Confiança Sempre!!!

Fontes: 

• https://vitruvius.com.br/revistas/read/arquitextos/18.212/6866
• https://sites.icmc.usp.br/rtvb/apostila.pdf
• https://repositorio.ufpe.br/bitstream/123456789/11981/1/DISSERTA%C3%87%C3%83O%20Roberto%20Tenorio%20Figueiredo.pdf 
• https://speakerdeck.com/hhamon/learning-design-patterns-with-symfony?slide=29
• https://refactoring.guru/
• https://netgen.io/learn/php-workshops/php-design-patterns
• https://phptherightway.com/pages/Design-Patterns.html
• http://www.facom.ufu.br/~bacala/ESOF/05b-Padr%C3%B5es%20Gof.pdf
• https://www.opus-software.com.br/design-patterns/