Padrões de Projeto

Links relacionados: Linguagens de Programação

Introdução

O Design Pattern (Padrão de Projeto/Desenho de Software) é uma descrição ou modelo de como resolver um determinado problema. Ele descreve a solução geral reutilizável para um problema recorrente no desenvolvimento de software orientado a objetos.

Nos Padrões de Projeto são definidas as relações e as interações entre as classes ou objetos em alto nível, sem se ater aos seus detalhes.

Um padrão de projeto define:

• Nome;
• Problema;
• Solução
• Quando aplicar a solução;
• Consequências.

Objetivos dos padrões de projetos:

• Facilitar a reutilização de soluções na fase de projeto do software;
• Estabelecer um vocabulário comum de desenho, facilitando comunicação, documentação e aprendizado dos sistemas de software.

Fundamentos

1977-1979: Um nome que possui grande influência no Padrão de Projeto é Christopher Alexander (Notes on the Synthesis of Form, 1977; A Pattern Language, 1979), que apresenta características ideias que um padrão de projeto de software deve possuir determinadas características e formato.

1987: Os programadores Kent Beck e Ward Cunningham, com base nos conceitos de Christopher Alexander, propuseram os primeiros padrões de projeto para a área da Ciência da Computação. Eles apresentaram um trabalho na conferência OOPSLA com alguns padrões para a construção de janelas na linguagem Smalltalk.

1995: Com o lançamento do livro Design Patterns: Elements of Reusable Object-Oriented Software, dos autores Erich Gamma, Richard Heml, Ralph Johnson e John Vlissides (GoF - Gang of Four), o padrão de projeto ganhou popularidade.

Após 1995: Depois disso, vários outros livros foram publicados, tais como Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development que introduziu um conjunto de padrões conhecidos como GRASP (General Responsibility Assignment Software Patterns).

Características

• Um padrão deve encapsular: um problema ou solução bem definida, independente, específica e que fique clara sua aplicabilidade.

• Todo padrão deve permitir a generalidade, de forma a permitir a construção de outros projetos a partir desse padrão.

• Equilíbrio: Quando um padrão é aplicado em um projeto/aplicação, em cada passo do processo suas ações e consequências podem ser analisada. Dessa forma, um equilíbrio pode ser encontrado por meio de:
  • uma análise racional da abstração dos dados empíricos;
  • uma observação da aplicação de padrões em artefatos tradicionais;
  • uma série convincente de exemplos e uma análise de soluções ruins ou fracassadas.

• Os padrões representam abstrações da experiência empírica ou do conhecimento cotidiano.

• Abertura: um padrão deve permitir que este possa ser estendido a níveis mais baixos de detalhes.

• Combinatoriedade: os padrões são relacionados hierarquicamente. Padrões de alto nível podem ser compostos ou relacionados com padrões com problemas de níveis mais baixo.

Formato

Além dessas características, há o seguinte formato que um padrão deve descrever:

1. Nome: uma descrição da solução, mais do que do problema ou do contexto.

1. 'Exemplo: uma ou mais figuras, diagramas ou descrições que ilustrem um protótipo de aplicação.

1. Contexto: a descrição das situações sob as quais o padrão se aplica.

1. Problema: uma descrição das forças e restrições envolvidos e como elas interagem.

1. Solução: relacionamentos estáticos e regras dinâmicas descrevendo como construir artefatos de acordo com o padrão, freqüentemente citando variações e formas de ajustar a solução segundo as circunstâncias. Inclui referências a outras soluções e o relacionamento com outros padrões de nível mais baixo ou mais alto.

Padrões GoF

Os padrões baseados na descrição do Gang of Four são classificados em três: (i) padrões de criação; (ii) padrões estruturais; e (iii) padrões comportamentais.

Padrões de Criação

Estes padrões estão relacionados com a criação de objetos.

• Abstract Factory: permite a criação de famílias de objetos relacionados ou dependentes por meio de uma única interface e sem que a classe concreta seja especificada;
• Builder: permite a separação da construção de um objeto complexo da sua representação, de forma que o mesmo processo de construção possa criar diferentes representações;
• Factory Method: permite as classes delegar para subclasses decidirem. O factory method permite delegar a instanciação para as subclasses.
• Prototype: permite a criação de objetos a partir de um modelo original, ou protótipo.
• Singleton: garante a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto.

Padrões Estruturais

Os padrões estruturais são a forma como as classes e objetos estão associados.

• Adapter:
• Bridge:
• Composite:
• Decorator:
• Facade:
• Flyweight:
• Proxy:

Padrões Comportamentais

Os padrões comportamentais estão diretamente ligados as interações e divisões de responsabilidades entre as classes e objetos.

• Chain of Responsibility:
• Command:
• Interpreter:
• Iterator:
• Mediator:
• Memento:
• Observer:
• State:
• Strategy:
• Template Method:
• Visitor:

Padrões GRASP

Os padrões do General Responsibility Assignment Software Patterns (or Principles), consistem de um conjunto de práticas para atribuição de responsabilidades a classes e objetos em projetos orientados a objeto.

Todos esses padrões do GRASP servem para a resolução de problemas comuns e bastante típicos de desenvolvimento de software orientado a objeto. Portanto, tais técnicas apenas documentam e normatizam as práticas já consolidadas, testadas e conhecidas no mercado.

Os padrões GRASP estão mais como uma ferramenta mental ou uma filosofia de design, mas que ainda assim são úteis para o aprendizado e desenvolvimento de um bom design de software. Note que alguns padrões GoF implementam soluções correspondentes com padrões GRASP.

A principal obra sobre o assunto foi o livro de Craig Larman: "Utilizando UML e Padrões".

Padrões

Os padrões utilizados pelo GRASP são os seguintes:

• Especialista na Informação:
• Criador: relacionado ao Factory Method do GoF
• Controlador: relacionado ao modelo MVC (Model-View-Controller) pode enviar comandos para sua visão associada para alterar a apresentação da visão do modelo. Também pode enviar comandos para o modelo para atualizar o estado do modelo.
• Acoplamento fraco:
• Alta coesão:
• Polimorfismo: (muitas formas) permite que referências de tipos de classes mais abstratas representem o comportamento das classes concretas que referenciam.
• Invenção Pura:
• Indireção:
• Variações Protegidas:

Discussões

Para alguns altores, os padrões de projeto apenas classificam evidências da falta de certos recursos em algumas linguagens de programação, tais como Java ou C++, por exemplo.

Peter Norvig demonstra que 16 dos 23 padrões do livro Design Patterns são simplificados ou eliminados com a utilização de recursos próprios das linguagens de programação Lisp ou Dylan.

Por fim, pode haver um aumento desnecessário da complexidade de um software ao se tentar excessivamente fazer o código se conformar aos padrões de projetos.