Padrões de Projeto

De Aulas
Revisão de 12h09min de 24 de março de 2014 por Admin (discussão | contribs) (→‎Padrões)
(dif) ← Edição anterior | Revisão atual (dif) | Versão posterior → (dif)

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.