Design patterns são soluções genéricas para problemas comuns e recorrentes que ocorrem em códigos de desenvolvimento de software. Neste artigo, você vai entender a importância dos design patterns no desenvolvimento de software, suas vantagens, como usá-los e um resumo de suas características.
Design patterns (padrões de projeto) são como uma planta de construção que você pode customizar para resolver um problema de projeto em seu código. Eles existem como um conceito geral para ajudar a resolver problemas comuns que surgem no desenvolvimento de softwares.
Para desenvolvedores de software, design patterns são poupadores de tempo e promovem o aumento da produtividade. Afinal, não há necessidade de criar uma solução do zero quando já existe uma que foi testada exaustivamente e comprovadamente funciona.
Além disso, os padrões se tornam facilmente identificáveis, tornando mais fácil a outros desenvolvedores entenderem o que está acontecendo no código criado por outra pessoa. Design patterns também deixam o código mais elegante e conciso.
Cada padrão identifica as informações necessárias para entender o problema de software e a solução, que é o resultado da relação entre as classes e os objetos necessários para implementá-la.
O que NÃO SÃO design patterns:
- Não são padrões de análise.
- Não são descrições de estruturas nem são projetos de aplicativos ou frameworks.
Com isso entendido, vamos dar uma olhada nas categorias de padrões de projetos.
“Padrões de design não resolvem o problema em si; eles ajudam a resolver o problema.”
Design patterns são “descrições de objetos e classes de comunicação que são personalizados para resolver um problema geral de projeto em um contexto específico”.
Qual é a importância dos design patterns no desenvolvimento de software?
A resposta é simples: os design patterns são usados porque facilitam o trabalho dos desenvolvedores, permitindo escrever um código melhor e com mais rapidez, o que acelera o processo de desenvolvimento, economiza tempo e, principalmente, oferece respostas a problemas que já ocorreram antes.
Para ilustrar, considere o Adapter, um dos 23 tipos de padrões, no cenário em que um cliente e um servidor precisam interagir um com o outro, mas não podem porque suas interfaces são incompatíveis.
Ao implementar um Adapter, você cria uma classe customizada que respeita a interface do servidor e define suas operações nos termos que o cliente espera. Esta é uma solução muito melhor do que alterar o cliente para corresponder à interface do servidor.
- A maioria dos padrões é descrita de forma muito enxuta para que os desenvolvedores possam reproduzi-los em diversos contextos. Em geral:
- A intenção do padrão descreve brevemente o problema e a solução.
- A motivação explica ainda mais o problema e a solução que o padrão torna possível.
- A estrutura das classes mostra cada parte do padrão e como elas estão relacionadas.
- O exemplo de código em uma das linguagens de programação populares facilita a compreensão da ideia por trás do padrão.
- Alguns catálogos de padrões listam outros detalhes úteis, como a aplicabilidade, etapas de implementação e as relações existentes entre padrões.
Quais são as vantagens de usar design patterns?
Aqui estão apenas algumas das vantagens de usar padrões em desenvolvimento de softwares, aplicativos e microsserviços.
- São reutilizáveis em vários projetos.
- Fornecem as soluções que ajudam a definir a arquitetura do sistema.
- Melhoram as experiências de engenharia de software.
- As alterações ou modificações tornam-se mais fáceis.
- Fornecem transparência ao design de um aplicativo.
- Torna o código reutilizável, livre de bugs e limpo.
- Acelera o processo de desenvolvimento.
- Reduz problemas comuns e recorrentes durante o processo de desenvolvimento.
- São soluções comprovadas e testadas, pois foram construídas com base no conhecimento e na experiência de desenvolvedores de software especializados.
Importante: Padrões não garantem a solução absoluta para um problema. Eles fornecem clareza à arquitetura do sistema e a possibilidade de construir um produto digital melhor.
As categorias de design patterns GoF
A importância dos Design Patterns começa a muito tempo atrás. Os tipos de padrões de design geralmente são divididos em três grandes categorias: Criacional, Estrutural e Comportamental. São conhecidos como “padrões GoF”, criados há décadas – no final deste artigo contamos a história dos padrões.
Os padrões GoF foram divididos e categorizados com base na natureza do problema que eles resolvem:
Padrão Criacional: Resolve a operação de instanciação de objetos. Isso quer dizer que o sistema vai solicitar um objeto de um determinado tipo e ele vem pronto, sob demanda.
Padrão estrutural: Organizam a estrutura das classes e os relacionamentos entre classes e objetos.
Padrão Comportamental: Delegam responsabilidades, definindo como os objetos devem se comportar e se comunicar.
Como selecionar/escolher um design pattern?
Entre as 23 opções de padrões GoF, aparentemente pode não ser fácil saber qual deles usar em um projeto.
E dizer que existem também outros tipos de design patterns, como o GRASP (General Responsibility Assignment Software Patterns (or Principles), que por sua vez tem 9 padrões divididos em básicos e avançados!
Mas com método é possível escolher o padrão mais adequado ao desenvolvimento de um projeto.
A primeira coisa a fazer é definir se o problema é fundamentalmente criacional, estrutural ou comportamental. Alguns problemas têm aspectos de dois ou até três problemas, e podem exigir misturar ou combinar dois ou mais tipos de padrões.
Veja algumas dicas sobre quais critérios levar em conta na hora de escolher o padrão mais apropriado:
- Considere como os padrões resolvem os problemas de projeto: como ajudam a encontrar objetos apropriados, determinar a granularidade do objeto, especificar interfaces de objeto, etc.
- Veja a intenção de varredura: a seção de intenção da especificação de cada padrão de projeto permite escolher o padrão de projeto apropriado.
- Estude como os padrões se relacionam: As relações entre os padrões direcionam a escolha de padrões ou grupos de padrões corretos.
Exemplo de aplicação de um design pattern
Até aqui, explicamos a importância dos Design Patterns, de forma básica, mas nada melhor para ilustrar suas aplicações do que um exemplo real.
Digamos que você esteja escrevendo um software para uma máquina que prepara café. Os principais ingredientes são café, leite e açúcar. Dependendo da sua preferência, você escolhe se quer ou não açúcar e leite.
A seguir, mostramos a aplicação do design pattern Builder para esse exemplo da máquina de café.
O que temos dentro da função main() é um objeto construtor para o qual passamos o tipo obrigatório de café. Vinculadas a essa chamada, determinamos outras chamadas, acrescentando as preferências dos outros ingredientes.
Ou seja, se outra pessoa quiser um café diferente, ela poderá facilmente “construí-lo”. Isso leva a uma enorme flexibilidade na construção de objetos.
Cada tipo de padrão tem assim as suas características de taxonomia e funções próprias.
Leia também:
- Refatorar, reescrever o código ou refazer o software do zero?
- As 10 principais tendências de desenvolvimento de software
- Low code: O que é, como usar e quando usar nas empresas
Limitações dos padrões de design pattern
É utópico encontrar um design pattern que resolva todos os problemas possíveis que surgem no desenvolvimento de software. Todo desenvolvedor sabe que em seu dia a dia surgem problemas surpreendentes, inevitáveis e até mesmo inexplicáveis.
Vale lembrar também que nenhum padrão é imutável ou encravado como regra pétrea. Se um padrão não funcionar, é possível alterá-lo para que se ajuste à dificuldade específica de um projeto. Nesse sentido, padrões podem ser comparados às bibliotecas, que podem ser modificadas para uso próprio ou distribuição.
É importante dizer ainda que os padrões de design não fazem parte da sintaxe de uma linguagem de programação. São formas de pensar e organizar soluções para problemas comuns.
Afinal, quando utilizar design patterns?
Suponha que há um problema que ocorre repetidamente durante o desenvolvimento de software, mas você conseguiu descobrir uma solução confiável para esse problema. Você pode não saber, mas já está utilizando um padrão, um modelo de abstração que pode ser aplicado em problemas da vida real.
Com padrões de design é a mesma coisa: não é preciso reinventar a roda para encontrar soluções para problemas comuns de desenvolvimento. Se você implementar um design pattern, sabe que a solução é consistente e funcionará porque já foi repetidamente testada e comprovada.
Quando usar:
Para saber quando usar padrões de projeto, é preciso saber se é possível usá-los, já que geralmente são aplicáveis às linguagens OOP (Programação Orientada a Objetos), categoria de linguagens baseada em objetos (por exemplo, classes, structs, etc.). Exemplos de linguagens OOP são Python, C++ e Java.
Isso quer dizer que apenas as linguagens OOP aceitam padrões? Não é bem assim.
Por muito tempo a importância dos Design Patterns foi atribuída exclusivamente para construções OOP. Felizmente, como os padrões descrevem soluções para problemas comuns, é possível refinar as aplicações.
Se um padrão não funcionar, é possível alterar a composição de diversas classes de funções para que se ajustem à dificuldade específica de um projeto — mas esse ponto ultrapassa os limites do artigo.
O importante é entender que se você aplicou um design pattern como uma solução mágica numa situação que não se encaixa, está criando mais um problema em vez de resolver o original. Quando os padrões são mal aplicados, eles afetam negativamente a portabilidade, extensibilidade e flexibilidade do projeto.
Ou seja, aplicar o padrão nem sempre é o caso e pode até resultar em aumento da complexidade ou duplicação do código quando aplicado a um problema que não foi definido pelo GoF.
Portanto, padrões de design não são necessariamente a solução definitiva para qualquer problema de desenvolvimento de software: os desenvolvedores devem pensar se é eficiente usá-los e se eles se encaixam no projeto ou não. Se não se encaixarem, será necessário procurar soluções alternativas.
BoF e GoF: como surgiram os design patterns?
Padrões de projeto não nasceram na computação. O conceito foi descrito pela primeira vez pelo arquiteto Christopher Alexander em “A Pattern Language: Towns, Buildings, Construction” (1977). É uma obra sobre arquitetura e habitabilidade comunitária que descreve uma linguagem para projetar o ambiente urbano. As unidades desta linguagem são padrões que descrevem a altura das janelas, quantos níveis um edifício deve ter, a dimensão das áreas verdes em um bairro e assim por diante.
O livro foi um sucesso e chegou até a OOPSLA ’90 (Object-Oriented Programming, Systems, Languages & Applications), uma conferência anual de pesquisa que ocorre nos Estados Unidos. Durante uma sessão Birds of a Feather (BoF), Erich Gamma e Richard Helm se conheceram e descobriram seu interesse comum: os padrões aplicados à computação.
Mais tarde, os dois se juntaram a Ralph Johnson e John Vlissides e escreveram “Design Patterns: Elements of Reusable Object-Oriented Software” (1994/1995). O livro até hoje é um best-seller e os autores ficaram conhecidos como “Gangue dos Quatro” (Gang of Four – GOF). Para muitos desenvolvedores, o GoF é o marco da programação orientada a objetos (OOP).
A UDS sabe da importância dos Design Patterns em desenvolvimento de software, e aplica as melhores técnicas em cada projeto. Quer garantia de qualidade nos códigos e excelência em seus projetos de software? Entre em contato e fale com nossos especialistas.
