Design Patterns

Design Patterns descrevem soluções reutilizáveis para determinados problemas no desenvolvimento de software. Eles não apresentam o código final para uma solução, mas sim um modelo de como resolver um problema em diversas situações.

Os design patterns de software foram baseados nos padrões de construções e cidades de Alexander et al. [1], eles descrevem padrões da seguinte maneira: “Cada padrão descreve um problema que ocorre repetidas vezes em nosso ambiente, e então descreve o núcleo da solução para esse problema, de tal forma que você pode usar esta solução um milhão de vezes, sem nunca fazê-lo da mesma forma duas vezes”. Esta afirmação também é verdade para o desenvolvimento de softwares orientados a objetos, pois, embora nós utilizamos objetos e interfaces ao invés de portas e muros, o núcleo de ambos tipos de padrões é a solução para um problema em um determinado contexto.

Os padrões devem ter quatro elementos essenciais:

  1. O nome do padrão: fornece uma maneira de descrever um problema, suas soluções e consequências em uma ou duas palavras;
  2. O problema: descreve quando utilizar o padrão;
  3. A solução: descreve os elementos do design, suas relações, responsabilidades e colaborações;
  4. As consequências: são os resultados da aplicação do desing pattern.

Um dos primeiros e mais bem recebidos livros sobre design patterns é o Design Patterns: Elements of Reusable Object-Oriented Software de 1995, dos autores Erich Gamma, Richard Helm, Ralph Johnson, e John Vlissides, conhecidos como Gang Of Four (GoF) [2]. Nesse livro são apresentados 23 padrões que são classificados de acordo com dois critérios: propósito e escopo. O primeiro define o que o padrão faz, podendo ser de criação, estrutural ou comportamental. O segundo critério especifica se o padrão se aplica a uma classe ou a um objeto.

Nas seções seguintes serão descritos cada um dos propósitos dos design patterns. A Seção 1 especifica os padrões de criação; a Seção 2 especifica os padrões estruturais; a Seção 3 especifica o padrões comportamentais; por fim, na Seção 4, ao final deste artigo, é apresentada uma tabela com os 23 design patterns divididos de acordo com os critérios que os classificam.

1. Padrões de Criação

Esses design patterns abstraem o processo de instaciação de seus objetos, deixando o sistema independente de como esses eles são criados, compostos e representados.

Padrões de criação se tornam importantes quando o sistema evolui de forma a depender mais na composição dos objetos do que em herança de classes, possibilitando os objetos serem compostos sem a necessidade de expor o seu interior como acontece na herança de classe.

Esses padrões encapsulam conhecimento sobre quais classes concretas são usadas pelo sistema e ocultam o modo como essas classes são criadas e montadas, permitindo configurar um sistema com objetos “produto” que variam amplamente em estrutura e funcionalidade.

A Figura 1 apresenta o modelo de um dos padrões de criação, o Factory Method.

Nesse modelo, o código irá lidar apenas com a interface Product, a maneira como ela é implementada é transparente para ele. O objeto do tipo Product poderá ser um objeto da classe ConcreteProduct ou qualquer outra classe que implemente esta interface. O Creator declara o método para a criação de um objeto do tipo Product, podendo implementar um método padrão ou apenas fornecer a assinatura que deve ser sobrescrita por outra classe. A classe ConcreteCreator sobrescreve o FactoryMethod de Creator para a criação de um objeto do tipo Product.

Class Diagram0

Figura 1 – O padrão Factory Method

2. Padrões Estruturais

O interesse de padrões estruturais é como classes e objetos são compostos para formar estruturas mais complexas. Estes padrões utilizam herança para compor interfaces ou implementações. Um exemplo disto é como heranças multiplas misturam duas ou mais classes em uma, o resultado é uma classe que combina as propriedades de suas classes pais. Este padrão é útil para fazer com que bibliotecas de classes desenvolvidas independentemente possam trabalhar juntas.

Na Figura 2 é apresentado um exemplo de padrão estrutura, o Adapter. Neste padrão, a classe Adapter faz a adaptação de Adaptee para funcionar como a interface Target.

Class Diagram0

Figura 2 – O padrão Adapter

3. Padrões Comportamentais

Os interesses de padrões comportamentais são os algoritmos e atribuições das responsabilidades entre objetos. Esses design patterns descrevem não somente os padrões de objetos e classes, mas também padrões de comunicação entre eles. Eles possuem um controle de fluxo complexo que é difícil de acompanhar em tempo de execução, tirando sua preocupação com esse controle e permitindo que você se concentre apenas no modo que os objetos são conectados.

A Figura 3 descreve um dos padrões comportamentais, o Observer. Neste padrão, o Subject possui um conjunto de Observers registrados e, ao haver alguma ação, ele notifica todos os Observers para realizar o comportamento esperado de quando ocorre a ação.

Class Diagram0

Figura 3 – O padrão Observer

4. Tabela de padrões

A Tabela 1 apresenta todos os padrões apresentados pela GoF [2].

Escopo

Propósito

De Criação Estrutural Comportamental
Classe Factory Method Adapter InterpreterTemplate Method
Objeto Abstract

Factory

Builder

Prototype

Singleton

Adapter

Bridge

Composite

Decorator

Facade

Flyweight

Proxy

Chain of Responsibility

Command

Iterator

Mediator

Memento

Observer

State

Strategy

Visitor

Tabela 1 – Padrões definidos pela GoF

Mais informações sobre esses Design Patterns podem ser encontradas em http://c2.com/cgi/wiki?DesignPatternsBook.

Referências

[1] Christopher Alexander, Sara Ishikawa, MurraySilverstein, Max Jacobson, Ingrid Fiksdahl-King, and Shlomo Angel. A Pattern Language. Oxford University Press, NewYork, NY, USA, 1977.

[2] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1995.

Links Externos

[1] http://c2.com/cgi/wiki?DesignPatternsBook

Por MATERA SYSTEMS

Postado em: 27 de fevereiro de 2014

Confira outros artigos do nosso blog

REST não é JSON

21 de agosto de 2017

Bruno Sofiato

[Webinar] Profile de aplicações Java com Oracle Mission Control e Flight Recorder

24 de julho de 2017

Danival Calegari

Criando Mocks de serviços REST com SoapUI

27 de junho de 2017

Monise Costa

JavaScript 6: diferença entre var, let e const

09 de maio de 2017

Otávio Felipe do Prado

Deixe seu comentário