Padrões de projetos: uma abordagem de forma geral

4 min readNov 9, 2020

Conhecimento e experiência aplicados e testados para solucionar problemas comuns

Talvez você ainda não tenha ouvido falar em Padrões de projetos ou Design Pattners, mas já pode ter usado algum desses padrões para realizar alguma abstração ou implementação de alguma solução, mesmo sem saber que fazia parte desse conceito. E se você já ouviu falar, mas ainda não entendeu do que se trata realmente, este texto vai te ajudar a conhecer e saber qual sua utilidade para os projetos de software.

Origem do conceito

O início deste conceito começou com o engenheiro civil Christopher Alexander, quando fez a publicação do seu livro A Pattern Language, em 1978, onde o mesmo conceitua e cria uma definição de padrão no âmbito do desenvolvimento de um projeto:

“Um padrão descreve um problema que ocorre inúmeras/par vezes em determinado contexto, e descreve ainda a solução para esse problema, de modo que essa solução possa ser utilizada sistematicamente em distintas situações.” (Alexander,1978)

O conceito de padrões se popularizou nos projetos de softwares em 1995, quando surgiu o que é conhecido como a Gangue dos quatro (Gang of Four ou GoF), formado por Erich Gamma, John Vlissides, Ralph Johnson, e Richard Helm. Esses autores que a partir do trabalho de Alexander, fizeram as adaptações e aplicaram todo o conhecimento obtido na criação de 23 padrões voltados para programação, que foram publicados em Padrões de Projeto -Soluções Reutilizáveis de Software Orientado a Objetos.

Conhecendo os padrões de projeto

O padrão pode ser entendido como uma solução que foi testada e aprovada para resolver um problema comum, que acontece repetidas vezes no desenvolvimento de projetos. Não se trata de uma forma específica e detalhada de resolver o problema, mas uma descrição generalizada por meio do conhecimento e experiência de outros projetistas que tiveram o mesmo problema.

Dito isto, é importante ressaltar que os padrões de projetos são ótimas ferramentas no desenvolvimento de softwares, pois eles além de resolverem problemas comuns de uma forma padronizada, permite que você aplique princípios que vão ajudar na manutenção do seu código, favorecendo assim o trabalho em equipe também, uma vez que entendido e usado os padrões, se torna algo comum, como uma linguagem ou código de comunicação usada pelos envolvidos no projeto.

Um padrão é composto por um nome, objetivo, problema, solução e as consequências, que juntos vão mostrar como deve ser resolvido o problema e quais benefícios serão alcançados por meio do seu uso, dessa forma é entendido que não basta conhecer a solução, mas também o problema, afim de saber se o padrão escolhido é a melhor solução.

Os padrões de projetos são classificados por afinidade em Creational, Structural e Behavional. No livro da Gang of Four, são apresentados 23 tipos, que estão divididos nesse grupo maior.

De forma bem intuitiva como o nome já diz os padrões criacionais, atuam no âmbito da criação de objetos, propondo flexibilização e reutilização do código. Os tipos dessa categoria são:

Factory Method;
Abstract Factory;
Builder;
Prototype;
Singleton.

Os padrões estruturais estão relacionados com interação entre os objetos e seus relacionamentos, a fim de montar uma estrutura maior, mais abrangente. Os tipos de estruturais são:

Adapter;
Bridge;
Composite;
Decorator;
Facade;
Flyweight;
Proxy.

Por sua vez, os padrões comportamentais cuidam da comunicação e designam as responsabilidades entre os objetos. Seus tipos são:

Chain of Responsibility;
Command;
Interpreter;
Iterator;
Mediator;
Memento;
Observer;
State;
Strategy;
Template Method;
Visitor.

Todos esses padrões são baseados na descrição de um problema e uma solução, demonstrando como deve ser feita a abstração e a possível implementação. A seguir é possível observar a exemplificação da atuação de um padrão de projeto.

Exemplo

Em uma aplicação para gerenciamento de logística que atualmente lida apenas com transporte rodoviário (caminhões), será necessário a inclusão de transportes marítimos (navios) para a expansão da aplicação. Na modelagem implementada até então a maior parte do código está na classe Caminhão, o que gerou um grande acoplamento da aplicação. Para resolver esse problema foi aplicado o padrão Factory Method com a seguinte solução:

https://refactoring.guru/pt-br/design-patterns/factory-method

Na solução ilustrada a cima, é proposto a implementação de um método fábrica que retorna objetos (produtos), que para a exemplificação seriam um objeto Caminhão e um objeto Navio. Desta forma será possível editar o código de suas subclasses, para retornar os objetos com suas especificidades.

Por fim as subclasses devem ter uma classe ou interface base em comum, no exemplo foi modelada a interface Transporte, que são implementadas por Caminhão e Navio, que agora podem fazer a implementação do método de entrega de acordo com suas indicações, conforme a imagem a cima.

Conclusão

O tema abordado neste texto foi introduzido, conceituado e exemplificado de forma bem generalista e resumida, que é um dos objetivos desta publicação, ser breve. No entanto, espero ter esclarecido os conceitos de padrões de projetos e ter despertado um interesse para maior aprofundamento neste tema tão importante para desenvolvimento de softwares.

Referências