Conceitos de padrões de projeto
Os primeiros registros de design patterns ou padrões de projeto foram publicados por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, em 1994, no livro Design patterns: elements of reusable object-oriented software. Estes padrões ficaram conhecidos como padrões GoF – Gang of Four, em referência aos quatro autores.
Além dos padrões GoF, há diversos outros padrões de projeto. Craig Larman, em 2004, no seu livro Applying UML and patterns, reuniu um conjunto de padrões sob o acrônimo GRASP – General Responsibility Assignment Software Patterns
(Padrões de Software para Atribuição de Responsabilidade Geral), que
funcionam como um guia no desenvolvimento orientado a objetos, apoiando a
organização por responsabilidades. O GRASP reúne nove padrões
relevantes para o desenvolvimento de sistemas OO dirigidos por
responsabilidades. Os nove padrões que compõem o GRASP são: Creator (criador); Information Expert (especialista); Low Coupling (baixo acoplamento); Controller (controlador); High Cohesion (alta coesão); Polymorphism (polimorfismo); Pure Fabrication (pura invenção); Indirection (indireção); Protected Variations (variações protegidas).
Os padrões de projeto descrevem os princípios fundamentais da
atribuição de responsabilidades a objetos. Esses padrões exploram os
princípios fundamentais de sistemas OO.
Embora a adoção de padrões não seja trivial para um
programador iniciante, este conceito tem sido adotado pela comunidade de
desenvolvedores e cada vez mais exigido por líderes nas fábricas de
software.
Como visto anteriormente, um código-fonte de um programa pode
degradar-se ao longo de sua vida. Por princípio, os padrões buscam
isolar as partes do código que são estáveis daquelas que são/serão mais
suscetíveis a mudanças. O resultado que se espera é ter aplicações nas
quais seja mais fácil efetuar procedimentos de manutenção, cujo código
seja mais facilmente compreendido pela equipe do projeto, aumentando
assim seu tempo de vida e postergando o início da degradação.
Os patterns são uma coleção de padrões de projeto de
software, que oferecem soluções para problemas conhecidos e recorrentes
no desenvolvimento de software. Um pattern descreve uma solução
comprovada para um problema recorrente, dando ênfase ao contexto em que
o problema ocorre e mostrando as consequências e o impacto de sua
solução.
Assim, os patterns são dispositivos que permitem que os programadores compartilhem conhecimento sobre o seu projeto.
Como desenvolvedores, sabemos que, quando programamos,
encontramos muitos problemas que ocorrem, ocorreram e irão ocorrer
novamente. A pergunta que sempre fazemos é: “Como vamos solucionar este
problema desta vez?”. Documentar um padrão é uma maneira de
podermos reusar e possivelmente compartilhar uma informação que
aprendemos em relação à melhor maneira de se resolver um determinado
problema de software.
As vantagens de se utilizar design patterns são muitas e incluem as seguintes:
- Os padrões já foram provados e refletem a experiência, o conhecimento e as soluções dos desenvolvedores que tiveram sucesso usando-os em seus trabalhos.
- Os padrões são reutilizáveis e oferecem uma solução pronta que pode ser aplicada a diferentes problemas.
- Os padrões proveem um vocabulário comum que pode expressar muitas soluções, de forma sucinta e objetiva.
No entanto, é importante lembrar que os padrões, por si só,
não garantem o sucesso do seu uso. A descrição do padrão indica quando
ele pode ser aplicado, mas apenas a experiência pode determinar quando
um padrão particular irá melhorar o projeto do sistema.
O principal objetivo de um design pattern é criar uma
abstração de um problema recorrente e apresentar uma solução viável,
além de poder compartilhar este conhecimento para que outras pessoas se
beneficiem dele. Assim, a documentação de um design pattern
deve ser feita de uma forma muito bem definida. De uma maneira geral, a
documentação de um padrão inclui a definição dos seguintes itens:
- Objetivos ou pré-requisitos que devem ser satisfeitos antes de se decidir aplicar um padrão.
- A motivação ou o contexto em que o padrão se aplica.
- Uma descrição da estrutura do programa em que o padrão será definido.
- Consequências do uso do padrão, positivas e negativas.
- Exemplos de uso e aplicação do padrão
O catálogo de padrões GoF contém 23 padrões e está, basicamente, dividido em três seções:
- Creational (Padrões de criação).
- Structural (Padrões estruturais).
- Behavioral (Padrões comportamentais).
Os padrões de projeto GoF são soluções para problemas
recorrentes no desenvolvimento de sistemas de software orientado a
objetos. O quadro 2 (veja a seguir) mostra a divisão destes padrões, no
contexto da programação orientada a objetos.
Os padrões de criação se referem à instanciação de objetos. Os
estruturais estão ligados com a composição de classes ou objetos, e os
comportamentais procuram caracterizar formas de interação entre classes e
objetos. Um padrão GoF também é classificado segundo o seu escopo em 2
outros grupos:
- Padrões com escopo de classe: definidos por relacionamentos de herança e em tempo de compilação.
- Padrões com escopo de objeto: encontrados no relacionamento entre os objetos definidos em tempo de execução.
Definição de padrões de criação
Padrões de criação auxiliam na concepção de sistemas
independentes do modo como os objetos são gerados, compostos e
representados. De acordo com Gamma et al. (1995), este tipo de padrão
abstrai o processo de instanciação, alterando a classe instanciada por
meio de herança.
Assim, os padrões de criação concentram-se na composição de
objetos complexos e no encapsulamento do comportamento de criação. Dessa
forma, pretende-se evitar a ocorrência de códigos embutidos definindo
pequenos grupos de características fundamentais, capazes de compor
estruturas mais complexas.
Os padrões de criação podem ser competitivos ou cooperativos.
Algumas técnicas se complementam, enquanto outras executam funções
similares de formas distintas. As cinco abordagens presentes no modelo
GoF são apresentadas a seguir:
Nenhum comentário:
Postar um comentário