Série Design Patterns em Python – Introdução aos Design Patterns

Neste artigo, nós iremos iniciar a nossa jornada com design patterns, além de aprender quais são os design patterns presentes no livro Padrões de Projetos: Soluções Reutilizáveis de Software Orientados a Objetos.

design patterns be like

Esta será uma série longa, na verdade, esta série será divida em vinte e quatro artigos (incluindo este).

Neste primeiro artigo, nós vamos aprender o que são os design patterns, quais são os principais padrões, e também um pouco de história.

Nos próximos artigos, eu irei explicar mais profundamente cada padrão de projeto, além de oferecer exemplos práticos de como aplicar o padrão em questão utilizando Python.

Porém, antes de começarmos é importante falar que um padrão de projeto não tem nada a ver com uma determinada linguagem de programação.




Os padrões de projetos são como uma receita de bolo para que, em determinada situação, você possa resolver o seu problema de uma maneira mais clara e elegante, ou pelo menos, de uma maneira padronizada.

Série Design Patterns em Python

Antes de mais nada, eu gostaria de deixar aqui o repositório no github que eu criei com os exemplos dessa série. Se acaso você queira conferir, basta acessar o link: https://github.com/ceb10n/design-patterns-with-python

O que são Design Patterns

Uma dúvida que muita gente tem quando está começando a programar é: O que é Design Pattern?

Os Design Patterns, ou em português, Padrões de Projetos, não são nada mais do que soluções catalogadas para problemas que ocorrem frequentemente no desenvolvimento de software em geral.




A ideia de catalogar um padrão de projeto não começou com o desenvolvimento de software.

Na verdade, a ideia por trás dos padrões de projetos em desenvolvimento de sistemas teve origem com o Christopher Alexander, um arquiteto.

Alguns anos antes do lançamento do famoso livro Padrões de Projetos: Soluções Reutilizáveis de Software Orientados a Objetos, do GoF, os famosos programadores Kent Beck e Ward Cunningham já vinham estudando maneiras de catalogar problemas comuns, e suas respectivas soluções.

Gang of Four Design Patterns

one does not simply gang of four

É muito difícil começar a falar de design pattern sem mencionar o famoso GoF, abreviação de Gang of Four.




O Gang of Four é um apelido dado aos autores do famoso livro Padrões de Projetos: Soluções Reutilizáveis de Software Orientados a Objetos, sendo eles:

  • Erich Gamma
  • Richard Helm
  • Ralph Johnson
  • John Vlissides

Trata-se de um livro lançado em 1994 com o intuito de documentar determinados designs de software que eles documentaram ao longo dos anos, para resolver problemas comuns até então.

Ao todo, o livro documenta vinte e três design patterns, separados entre três tipos, sendo eles:

  • Criacional
  • Estrutural
  • Comportamental

Creational Design Patterns

tirinha design patterns - vida de programador

Os padrões de projetos criacionais são os padrões relacionados a criação de objetos complexos.

Abstract Factory

O padrão de projeto Abstract Factory foi concebido pensando na criação de objetos sem a necessidade de especificar o seu tipo concreto.

Abstract Factory Design Pattern UML

Fonte: Wikipedia

Builder

O padrão Builder apresenta uma maneira elegante e customizável de criar objetos complexos.

Builder Design Pattern UML

Fonte: Wikipedia

Factory Method

O design pattern Factory é um dos mais conhecidos e utilizados, principalmente em linguagens mais verbosas como Java ou C#.

Ele é utilizado, como já era de se esperar, na criação de objetos complexos.

Factory Method Design Pattern UML

Fonte: Wikipedia

Prototype

O Prototype é um padrão de projeto utilizado para a criação de objetos a partir de outros objetos existentes.

Prototype Design Pattern UML

Fonte: Wikipedia

Singleton

meme the singleton

Talvez o padrão de projeto mais conhecido e mais odiado, o padrão de projeto Singleton serve para garantir a existência de apenas uma única instância de um determinado objeto.

Singleton UML class diagram

Fonte: Wikipedia

Structural Design Patterns

Adapter

O design pattern Adapter oferece a oportunidade de trabalhar com objetos que não necessariamente são compatíveis, através de uma interface de comunicação entre eles.

Adapter Design Pattern UML

Fonte: Wikipedia

Bridge

O Bridge talvez seja um design pattern mais difícil de explicar brevemente, e ele acaba sendo mais fácil de observar olhando a implementação propriamente dita.

Mas o intuito do padrão Bridge é desacoplar uma abstração, permitindo variações independentes em suas implementações.

Bridge Design Pattern UML

Fonte: Wikipedia

Composite

O padrão Composite por outro lado, é mais simples de explicar.

Ele pega um determinado grupo de objetos e os transforma em um único objeto.

Composite Design Pattern UML

Fonte: Wikipedia

Decorator

O padrão de projeto Decorator é bem famoso, e muito utilizado.

O seu principal objeto é permitir que o comportamento de um determinado objeto seja estendido, ou complementado dinamicamente durante a execução do programa.

Decorator Design Pattern UML

Fonte: Wikipedia

Facade

Para quem já programou em Java, esse com certeza é uma figurinha carimbada.

A ideia por trás do Facade é oferecer uma interface de comunicação simples, facilitando o trabalho com operações mais complexas.

Facade Design Pattern UML

Fonte: Wikipedia

Flyweight

O Flyweight talvez não seja tão conhecido, porém ele pode ser muito importante em determinados casos. A sua função é diminuir o custo de objetos complexos e pesados.

Flyweight Design Pattern UML

Fonte: Wikipedia

Proxy

Este é um padrão de projeto que talvez não seja tão conhecido diretamente entre as pessoas. Ele é amplamente utilizado nos ORMs por exemplo.

Ele nada mais é do que uma interface para outro objeto, com o intuito de facilitar o trabalho, adicionar novas funcionalidades, etc.

Proxy Design Pattern UML

Fonte: Wikipedia

asked to code something simple uses every design pattern from gang of four

Behavior Design Patterns

Chain of Responsibility

Assim como os demais padrões de projeto desta parte do artigo, o design pattern Chain of Responsibility é utilizado para delegar ações através de uma série de objetos que serão executadas.

Chain of Responsibility Design Pattern UML

Fonte: Wikipedia

Command

O padrão de projeto Command funciona como um encapsulador de ações e seus respectivos parâmetros.

Command Design Pattern UML

Fonte: Wikipedia

Interpreter

O padrão Interpreter não é um dos padrões de projeto mais conhecidos e / ou utilizados, porém a sua missão é interpretar uma determinada linguagem especializada.

Interpreter Design Pattern UML

Fonte: Wikipedia

Iterator

Esse sim é um padrão de projeto conhecido. Aliás, fazemos uso constante dele, seja direta ou indiretamente.

O padrão de projeto Iterator serve para que um conjunto de elementos de um objeto sejam acessados sequencialmente, sem expor a sua representação e/ou implementação.

Iterator Design Pattern UML

Fonte: Wikipedia

Mediator

O design pattern Mediator é aquele padrão de projeto que para que os outros não sujem as mãos, ele vai lá e faz o trabalho sujo.

A sua função é diminuir o acoplamento de diversos objetos, sendo ele o único responsável por conhecer e manipular tais objetos, sendo ele o único a “sofrer” com o acoplamento do código.

Mediator Design Pattern UML

Fonte: Wikipedia

Memento

O padrão de projeto Memento é muito utilizado quando estamos trabalhando com Event Sourcing.

A missão do Memento é permitir que um determinado objeto possa ser construído e reconstruído dado um determinado estado prévio.

Memento Design Pattern UML

Fonte: Wikipedia

Observer

Talvez muitos não saibam, mas está ai o padrão de projeto largamente utilizado no front end hoje em dia.

Ele nada mais é do que um padrão para publicar e receber eventos.

Observer Design Pattern UML

Fonte: Wikipedia

State

O padrão de projeto State é um dos meu preferidos, apesar de não utilizá-lo muito.

A missão do design pattern State é permitir que um objeto mude o seu comportamento a partir da mudança de seu estado.

State Design Pattern UML

Fonte: Wikipedia

Strategy

O padrão de projeto Strategy é o famoso design pattern dos descontos e impostos.

Isso porque é muito comum encontrar exemplos do Strategy por ai sendo aplicado na seleção do algorítimo de imposto, ou um determinado desconto.

O Strategy define uma série de algorítimos especializados que podem ser escolhidos e executados em tempo de execução do seu programa.

Strategy Design Pattern UML

Fonte: Wikipedia

Template Method

Este padrão de projeto eu também acho muito bacana. O design pattern Template Method define uma espécie de esqueleto para a execução de determinado algorítimo.

Ele faz uso de classes abstratas fazendo com que as classes filhas implementem os algorítimos especializados.

Template Method Design Pattern UML

Fonte: Wikipedia

Visitor

O padrão de projeto Visitor visa separar o algorítimo de um objeto, movendo a sua estrutura de métodos para outro objeto.

A ideia aqui é poder adicionar novas funcionalidades sem precisar alterar diretamente a classe original.

Visitor Design Pattern UML

Fonte: Wikipedia

Conclusão

Conhecer os principais padrões de projetos utilizados é algo muito importante para todo desenvolvedor.

Eles oferecem maneiras padronizadas de resolver problemas, o que facilita o entendimento entre diversos profissionais que venham atuar no mesmo código.

Porém, é necessário também utilizá-los com parcimônia, já que eles podem inserir uma camada de complexidade desnecessária no seu código.

E ai, o que você achou do artigo? Já conhecia os padrões de projeto do GoF?

Não deixe de comentar abaixo a sua opinião! E se ficou alguma dúvida, não exite em perguntar!

Um grande abraço 😉

Links Importantes e Referências




Leave a Reply