Sign in Subscribe
Arquitetura

Entenda: Design Patterns

Descubra os princípios dos padrões de projeto na programação (design patterns) e aprenda como aplicar essas soluções reutilizáveis para melhorar a qualidade e a eficiência do seu código.

Marlon Vismari

• 3 min read
Entendendo um pouco sobre os padrões de projetos, design patterns
Pequenos blocos de madeira do lado esquerdo. Do lado direito, o texto "Design Patterns: uma breve introdução aos padrões de projeto".

Quando o profissional começa a desenvolver, bem lá no início da carreira, geralmente desenvolve sistemas apenas "para funcionar", mas não "pronto para expandir". Conforme o desenvolvedor enfrenta desafios, nesse momento procura tirar o máximo proveito da programação Orientada a Objetos (OOP). Mas afinal, o que isso tem a ver com Design Patterns?

Conceito

Design patterns, em português "padrões de design", nada mais é que soluções conhecidas para resolver problemas comuns na engenharia de software.

Em uma analogia simples, as construções de casas seguem basicamente "a mesma receita" desde a construção da base até o telhado. O mesmo se aplica para o sistema hidráulico e elétrico. Trazendo para o universo de um software, imagine um e-commerce onde é possível logar com usuário e senha da própria loja, Facebook ou Google. Qual a melhor forma de construir isso para que fique fácil de integrar outras formas de login? Ou então como fazer para a loja poder integrar diversos meios de pagamento (MercadoPago, PagSeguro, etc.) sem precisar colocar dezenas de "ifs"? Esses problemas são resolvidos com Design Patterns.

Dentro desse mundo existem vários patterns, neste artigo esse tema será abordado de forma resumida para que o leitor compreenda a base. Posteriormente, serão publicados outros artigos com detalhes mais técnicos e de aplicabilidade.

Um pouco de história

Em 1994, os Autores Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, mais conhecidos como GoF (Gangs of Four - Gangue dos 4, em português), publicaram uma coleção de 23 Design Patterns no livro "Design Patterns: Elements of Reusable Object-Oriented Software". Esse é um dos livros mais populares e o primeiro a falar sobre Design Patterns como elementos reutilizáveis na orientação a objeto.

Classificações e Patterns

Cada pattern tem um nível de complexidade para ser aplicado no projeto. Entretanto, pode-se categorizar de acordo com a proposta de cada um deles. Hoje será apresentado 3 grupos e um "resumo do resumo" de cada pattern.

  1. Creational Patterns (Padrões para criação de objetos);
Esse padrão restringe a criação de uma única instância da classe. Alguns autores consideram um anti-pattern. Mas detalharei em outro artigo.
  • Factory Method;
Nesse padrão uma "fábrica" (factory) é responsável por instanciar as classes.
  • Abstract Factory;
Nesse padrão uma "fábrica" (factory) é responsável por outras "fábricas" (factories).
  • Builder;
Nesse padrão um objeto (builder) é criado passo por passo. Um método é responsável por retornar a instância do objeto.
  • Prototype.
Nesse padrão cria-se um novo objeto a partir de um existente e você modifica de acordo com os requerimentos.

2. Behavioral Patterns (Padrões de comportamento);

  • Chain of Responsibility;
Nesse padrão diminui-se o acoplamento passando por uma cadeia de objetos. Geralmente usamos para eliminar os "ifs" exagerados.
  • Command;
Nesse padrão os objetos são reduzidos a um método de invocação sem parâmetros.
  • Iterator;
Nesse padrão você percorre uma coleção de uma forma simples sem saber da estrutura de fato da coleção (grafo? lista? pilha?).
  • Mediator;
Nesse padrão os objetos necessitam de um "mediador" para comunicarem entre si. Diga adeus as interações caóticas.
  • Memento;
Nesse padrão um objeto pode voltar ao estado anterior sem que precise saber dos detalhes da implementação.
  • Observer;
Nesse padrão objetos são notificados após ocorrência de um determinado evento (Subscription).
  • Stratetegy.
Nesse padrão uma classe "contexto" é responsável por delegar e chamar os diversos objetos "estratégias".
  1. Structural Patterns (Padrões estruturais).
  • Adapter;
Nesse padrão objetos com interfaces incompatíveis passam a interagirem entre si.
  • Bridge;
Nesse padrão você divide uma classe grande em classes menores que estejam intimamente ligadas através da abstração e implementação, tornando cada uma delas independentes.
  • Composite;
Nesse padrão os objetos são tratados como se fossem estruturas "em árvore". O acesso a cada objeto dessa árvore é como se fossem objetos individuais.
  • Decorator;
Nesse padrão um comportamento é adicionado a um objeto sem mudar a estrutura desse.
  • Facade;
Nesse padrão uma classe "fachada" é usada na aplicação e "esconde" (abstrai) todas as chamadas complexas que você deveria fazer na aplicação.
  • Flyweight;
Nesse padrão o foco é economizar memória compartilhando partes similares de um objeto ao invés de criar novas instâncias.
  • Proxy.
Nesse padrão um objeto "meio de campo" é colocado para controlar o acesso de um objeto a outro.

Considerações Finais

Esse artigo tem por finalidade introduzir o tema ao leitor. Em breve serão publicados outros artigos mais aprofundados para cada pattern bem como explicar a aplicação no dia a dia do Engenheiro de Software.

Inscreva-se para mais conteúdos como este

Enter your email
Subscribe