Todo software é intangível e abstrato. Isso significa que não estão limitados pelas leis da física ou restritos as propriedades dos materiais. Segundo Sommerville (2011), isso facilita para a Engenharia de Software, porque não há limites naturais para o potencial do software. No entanto, essa falta de restrições físicas contribuem para que softwares se tornem extremamente complexos rapidamente, difíceis de entender e até mesmo caros para alterações.
![]() |
Entendendo padrões de projeto, (Ilustração: adaptada de Freepik) |
Um dos paradigmas mais influentes no desenvolvimento de software é o paradigma de orientação a objetos. Projetar um software orientado a objetos é uma tarefa difícil. Projetar um software reutilizável orientado a objetos é ainda mais difícil. Padrões de projetos (também conhecidos como Design Patterns) lidam com problemas comuns ligados ao desenvolvimento de sistemas de software orientados a objetos e apresentam soluções convenientes, eficazes e eficientes para cada tipo de problema. Nesse artigo, você conhecerá uma visão geral (e teórica) sobre padrões de projetos e sua importância.
O que é um padrão
Dicionários trazem significados diversos do que vem a ser um padrão, sendo alguns deles:
1. O que serve de base ou norma para avaliação; medida.
2. Objeto que serve de modelo à feitura de outro.
Padrões são observáveis a partir de uma perspectiva comparativa. Quando surge um problema elementar em um projeto, novatos podem sentir dificuldades em resolvê-lo e tentarão desenvolver uma solução, também elementar, do zero. Já projetistas de sistemas de software experientes reutilizarão soluções testadas, aprovadas e que funcionaram no passado. Isso acontece porque há um padrão em problemas elementares e, a partir disso, foi possível o desenvolvimento de soluções padrões.
Usar soluções já existentes evita a reengenharia, poupa tempo e é mais confiável do que construir e padronizar uma solução nova para um problema já conhecido (a não ser que esse seja realmente o objetivo). E nenhum programador é perfeito. Max Kanat-Alexander (2012) nos fala que mesmo bons programadores introduzirão aproximadamente 1 erro a cada 100 linhas de código que escrevem e com isso explica a Lei da Probabilidade de Erros:
A chance de introduzir um erro em seu programa é proporcional à quantidade alterações que você faz nele.
Explicado o que é um padrão e a sua importância, agora é preciso entender o que é um projeto. E para este contexto, assumiremos padrão como um modelo.
O que é um projeto
Segundo o Guia PMBOK (2013):Projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.
Todo projeto é temporário porque tem começo, meio e fim. Mas isso não significa necessariamente que a duração do projeto é curta ou que o termo se aplique a longevidade do produto, serviço ou resultado exclusivo.
O resultado de cada projeto deve ser objetivamente único. Se um software está sendo desenvolvido como uma API REST que fornecerá dados demográficos sobre municípios do estado de São Paulo, ele não poderá, também, ser um módulo financeiro de um ERP, porque são objetivos diferentes. Para este contexto, assumiremos projeto como uma solução.
Os principais padrões de projetos
Visando resolver problemas únicos, os padrões de projeto são modelos de soluções simples que foram desenvolvidas e aperfeiçoadas ao longo do tempo por projetistas experientes. Eles tornam projetos orientados a objetos mais flexíveis, modulares, reutilizáveis e compreensíveis. Os padrões aqui apresentados foram catalogados por Erich Gamma, John Vlissides, Ralph Johnson e Richard Helm (também conhecidos como GoF - Gang of Four) e classificados em três propósitos:
- de Criação,
- Estrutural e
- Comportamental.
Segundo Erich Gama e os demais autores (2000), essa é uma definição mais precisa do termo "padrão de projeto":
São descrições de objetos e classes comunicantes que precisam ser personalizadas para resolver um problema geral de projeto num contexto particular.
Todo padrão de projeto geralmente possui quatro elementos: um nome, o problema, a solução e as consequências. Os principais são exibidos na tabela a seguir.
Propósito | ||||
De criação | Estrutural | Comportamental | ||
---|---|---|---|---|
Escopo | Classe | Factory Method | Adapter (class) | Interpreter |
Template Method | ||||
Objeto | Abstract Factory | Adapter (object) | Chain of Responsability | |
Builder | Bridge | Command | ||
Prototype | Composite | Iterator | ||
Singleton | Decorator | Mediator | ||
Façade | Memento | |||
Flyweight | Observer | |||
Proxy | State | |||
Strategy | ||||
Visitor |
Quanto aos elementos que compõem cada padrão, é válido saber que:
- Nome: identifica o padrão e suas características.
- Problema: descreve em que situação devemos aplicar o padrão.
- Solução: conjunto de elementos, responsabilidades, relacionamentos e colaborações que constituem o padrão.
- Consequências: são os resultados e análises das vantagens e desvantagens da aplicação do padrão.
Nos próximos artigos, veremos cada um desses padrões da tabela. Eles podem ser implementados em qualquer linguagem de programação OO como Java, PHP, C#, C++, Python etc. Vale ressaltar que alguns padrões de projeto podem ser expressos mais facilmente por uma linguagem e menos por outra. E em algumas linguagens alguns padrões podem nem ser necessários.
O que você aprendeu
Aprendemos que um padrão de projeto é um modelo de solução para problemas elementares. Tanto esses problemas quanto suas respectivas soluções fazem parte do desenvolvimento de software orientado a objetos.
Também aprendemos que é importante o uso de padrões de projeto porque são soluções que já foram desenvolvidas, testadas, analisadas e nos poupa da reengenharia permitindo que o foco se volte aos aspectos mais pertinentes do desenvolvimento de software.
Referência Bibliográfica
GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Padrões de projeto: soluções reutilizáveis de software orientado a objetos. Porto Alegre: Bookman, 2000.
KANAT-ALEXANDER, M. As leis Fundamentais do Projeto de Software. São Paulo: Novatec; Sebastopol, CA: O'Reilly, 2012.
PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK). 5. ed. Newtown Square: Project Management Institute, 2013.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.
Para citar esse artigo:
Excelente! Mas saberia informar algo sobre reactor e proactor patterns para desenvolvimento?
ResponderExcluirObrigado pelo comentário, Catarino :)
ExcluirSão padrões que não estão na série deste artigo, mas no futuro falaremos sobre
Obrigado pelo artigo. Encontrei mais informações sobre padrões de design em português aqui: https://refactoring.guru/pt-br/design-patterns
ResponderExcluirOi, muito obrigado pelo comentário e pelo material :)
ExcluirFiz uma leitura breve e gostei bastante da qualidade