Olá,

Não sei se sabem, mas Design Patterns são realmente um tema do qual eu gosto muito de falar e do qual sou extremamente fascinado. Por isso gostaria de começar uma série de artigos abordando o tema. Espero que aproveitem!

Design Patterns…

“Os Design Patterns não exigem nenhum recurso incomum da linguagem, nem truques de programação surpreendentes para impressionar seus amigos e gerentes.” (GoF, 1995, prefácio vii)

Um Design Pattern (Padrão de Projeto) é uma solução para um problema recorrente de modelagem de um software orientado a objetos. É composto por descrições de objetos e classes comunicantes que precisam ser personalizadas para resolução de um problema geral de projeto dentro de um contexto particular. (GoF, 1995, p. 20) (Freeman, 2005, p. 47/460)

Conforme a figura acima, um padrão está sempre relacionado a um contexto (problema), sendo que o contexto é a situação à qual o padrão é aplicável. Um padrão deve possuir a capacidade de ser adaptável (customizável) a outros contextos que possuam o mesmo problema de modelagem orientada a objetos, beneficiando a aplicação com soluções planejadas e testadas por outros profissionais. (Freeman, 2005, p. 47/460) (Grand, 2002, p. 1) (Silva e Araujo, 2008, p. 44)

“Design Patterns, ou padrões de modelagem, podem ser definidos como soluções já testadas para problemas de modelagem que ocorrem com freqüências em situações específicas.” (Oliveira, 2009)

Como Alexandrescu (2001, p.3) afirma: a engenharia de software, talvez mais do que as outras engenharias, possui uma rica possibilidade de variações. Nós podemos fazer a mesma coisa de diversas formas, e todas possuem infinitas nuances entre o certo e o errado. Existe uma escala comparativa que diverge quanto a vantagens e desvantagens de tais soluções; Esta definirá qual solução é mais competente para a resolução do problema em mãos.

“Cada caminho abre um novo mundo. (…) Nem sempre a solução que parece ser aceitável é a melhor para ser posta em prática.”. (Alexandrescu, 2001, p.4)

A partir da idéia de que Design Patterns são baseados na reutilização de soluções que funcionaram no passado (GoF, 1995, p. 18), podemos, então, partir do pressuposto de que a experiência “permite aos desenvolvedores aproveitarem toda a sua sabedoria” (Grand, 2002, p. 1). Alexandrescu e Grand ainda dizem que, conforme os desenvolvedores ganham experiência, eles reconhecem a similaridade entre novos problemas e problemas que foram resolvidos no passado e passam a relacionar um determinado padrão a um problema específico, e então, imediatamente determinam a sua solução. (Alexandrescu, 2001, p.4) (Grand, 2002, p. 1)

“A diferença mais importante entre um arquiteto de software experiente e um iniciante é o conhecimento do que funciona e do que não funciona (…) Arquitetos de software experientes são como bons jogadores de Xadrez: eles podem ver mais movimentos à frente. Isso leva tempo para aprender.” (Alexandrescu, 2001, p.4)

Origem dos Design Patterns Computacionais.

A idéia da utilização de padrões iniciou-se no ramo da arquitetura. Christopher Alexander, um engenheiro civil professor em Berkeley, notou que, para resolver determinados problemas, sempre utilizava um determinado grupo de padrões arquitetônicos. E a partir deste pensamento, Alexander deu início escrevendo dois livros: “The timeless way of building” e “A Pattern Language”, que descreviam padrões comuns em construções e planejamentos urbanos. As ideias presentes nestes dois livros foram aplicadas em diversas áreas, além da arquitetura, incluindo o desenvolvimento de software. (Grand, 2002, p. 4) (GoF, 1995, p. 19) (Freeman, 2005, p. 476)

Segundo o próprio Christopher Alexander (Oliveira, 2004), “cada pattern descreve um problema que ocorre com frequência em nosso ambiente, e então descreve o núcleo da solução para tal problema, de maneira que possamos utilizar esta solução milhares de vezes”. A figura abaixo ilustra a ideia de que um padrão engloba um problema e uma solução.

Em 1987, a partir dos conceitos de Christopher Alexander, os programadores Kent Beck e Ward Cunningham propuseram os primeiros padrões de projeto para a área da computação. Em um trabalho para a conferência OOPSLA (Conferência da ACM sobre Sistemas, Linguagens e Aplicações Orientadas a Objetos), eles apresentaram alguns padrões para a construção de janelas na linguagem Smalltalk. Nos anos seguintes Beck, Cunningham e outros seguiram com o desenvolvimento desta ideia.

No ano de 1995, Erick Gamma, Richard Helm, Ralph Johnson e John Vlissides deram início à revolução dos Design Patterns com o lançamento do livro “Design Patterns – Elements of Reusable Object-Oriented Software”. Este livro possui todos os padrões fundamentais, mas não é o texto final sobre Design Patterns. O campo se expandiu substancialmente após sua publicação, mas este é o primeiro e mais definitivo. Os quatro autores são conhecidos informalmente como “GoF” ou “Gang of Four”. (Freeman, 2005, p. 476)

Vocabulário Comum.

Design Patterns apresentam um vocabulário comum de desenho, facilitando a comunicação, a documentação e o aprendizado dos sistemas de software. O vocabulário comum de Design Patterns utiliza uma linguagem compartilhada que maximiza o valor da comunicação.

“Não subestime o poder de um vocabulário compartilhado, ele é um dos maiores benefícios do Design Patterns.” (Freeman, 2005, p. 474)

Segundo GoF (GoF, 1995, p. 19) e Craig Larman (Larman, 2004, p. 230), o nome de um pattern é uma referência que pode ser utilizada para descrever um problema de projeto, suas soluções e consequências. Isso permite um nível mais alto de abstração durante o período de análise, além de criar um vocabulário de projeto que nos permita documentar, agrupar ideias em um conceito ou até mesmo conversar com nossos colegas em um nível mais alto de entendimento e rapidez.

Como afirma Freeman (2005, p. 45), a comunicação entre desenvolvedores torna-se muito mais eficiente com a utilização de vocabulários compartilhados, pois não estamos apenas utilizando um nome de conhecimento geral, mas estamos agregando um conjunto inteiro de qualidades, características e restrições pertencentes ao padrão de uma palavra. Quando utilizamos um vocabulário compartilhado, estamos dizendo mais com menos, pois logo que nos referimos a um nome, outros desenvolvedores sabem precisamente o design que temos em mente.

Catálogos de Padrões.

Os padrões são descritos e documentados envolvendo um problema, um contexto e uma solução. Após serem corretamente documentados, tais padrões são inseridos dentro de Catálogos de Padrões, que por sua vez descrevem detalhadamente um conjunto de padrões, bem como o seu relacionamento com os demais. O primeiro catálogo de padrões foi o catálogo GOF clássico, que possui 23 padrões de projetos fundamentais. Muitos outros catálogos de padrões estão sendo publicados em diversas áreas de especialização, como software para empresas, sistemas concorrentes e sistemas comerciais. (Freeman, 2005, p. 462) Alguns dos catálogos mais conhecidos são:

1 – Catálogo GRASP

“Os padrões GRASP descrevem princípios fundamentais de projeto baseado em objetos e atribuição de responsabilidades aos mesmos” (Larman, 2004, p. 231)

O catálogo GRASP (General Responsibility Assignment Software Patterns) foi introduzido por Craig Larman em seu livro “Applying UML and Patterns”. Os padrões GRASP descrevem os princípios fundamentais da atribuição de responsabilidades a objetos de um projeto, expressas na forma de padrões. Esses padrões exploram os princípios fundamentais de sistemas OO. Sua aplicação é tão fundamentada nos princípios Orientados a Objetos, que podemos dizer: "Se você conhece os padrões GRASP, pode dizer que compreende o paradigma orientado a objetos". Sua divisão é composta por cinco padrões fundamentais e quatro padrões avançados. (Freitas, 2009, p. 12) A tabela abaixo apresenta os nove patterns pertencentes ao catálogo GRASP e suas respectivas subdivisões.

2 – Catálogo GOF

GoF é o catálogo clássico com 23 padrões de projetos fundamentais. Este catálogo é constituído por todos os padrões documentados no livro "Design Patterns – Elements of Reusable Object Oriented Software", de 1995, que deu propulsão a todo o campo de Design Patterns. O catálogo GoF é um conjunto de padrões de projetos relacionados entre si. Para cada padrão, há um gabarito seguido de uma descrição detalhada de seu funcionamento. Tal descrição define aspectos como: nome do padrão, intenção e objetivo, motivação, aplicabilidade, estrutura, participantes, colaborações, conseqüências, implementação, usos reconhecidos e padrões relacionados. (GoF, 1995, p. 22) (Freeman, 2005, p. 477)

O catálogo GoF ainda possui três categorias que agrupam os padrões de acordo com seus respectivos propósitos. Tais categorias são:

Padrões Criacionais – “são padrões que objetivam resolver questões relacionadas com a criação de objetos” (Santos, 2009, p. 55). Padrões: Abstract Factory, Builder, Factory Method, Prototype e Singleton;

Padrões Estruturais – “buscam solucionar situações que envolvam a composição de objetos ou classes” (Santos, 2009, p. 55). Padrões: Adapter, Bridge, Composite, Decorator, Façade, Flyweight e Proxy;

Padrões Comportamentais – “caracterizam-se por meios de solucionar questões que envolvem a interação e responsabilidade entre objetos e classes” (Santos, 2009, p. 55). Padrões: Chain of Responsability, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method e Visitor.

Além da classificação por propósitos (criação, estruturação e comportamento), os criadores adicionam um segundo critério de agrupamento, chamado escopo, que determina se o padrão pode ser aplicado primariamente a classes ou objetos. Os padrões para classes lidam com o relacionamento entre classes e suas subclasses. Os padrões para objetos envolvem o relacionamento entre objetos que podem ser alterados durante a execução do programa e são mais dinâmicos. (GoF, 1995, p. 25/26) A tabela abaixo ilustra os patterns pertencentes ao catálogo GOF, e suas respectivas subdivisões.

 

Outros autores preferem organizar os padrões de outra maneira, baseando-se nas formas como eles se relacionam. (GoF, 1995, p. 26) A figura a seguir ilustra tal relacionamento graficamente.

Segundo o GoF (1995, p. 26), existem muitas maneiras de organizar os padrões de projeto. Ter múltiplas maneiras de pensar a respeito deles aprofundará sua percepção sobre o que fazem, como se comparam e quando aplicá-los.

3 – Catálogo SOA

SOA (Service Oriented Architecture) pode ser traduzido como arquitetura orientada a serviços. É um estilo de arquitetura de software cujo princípio fundamental é a implementação de aplicações na forma de serviços. Quando desenvolvemos um projeto SOA, devemos prestar atenção aos milhares de detalhes de nosso design para sempre garantirmos a sua reusabilidade. Design Patterns SOA ajudam a estabelecer e fortalecer a arquitetura SOA dentro do ciclo de constantes alterações sofrido pelos projetos ao longo do tempo. (Erl, 2008, p. 3)

Design Patterns SOA não são específicos para uma plataforma ou indústria de software em específico. Tais padrões são simplesmente técnicas de modelagem que auxiliam na superação de obstáculos comuns associados à computação orientada a serviços. (Erl, 2008, p. 5)

Cada Design Pattern SOA fornece uma solução de modelagem como forma de suporte a um problema recorrente à orientação a serviços. Alguns padrões deste catálogo são baseados em padrões de outros catálogos, mas são documentados no contexto específico da arquitetura SOA. (Erl, 2008, p. 6)

Design Patterns SOA como um modelo de arquitetura devem ser divididos em grupos, cada um representando um escopo comum de implementação: (Erl, 2008, p. 3)

Service Architecture (Arquitetura de Serviço) – A arquitetura de um serviço simples;

Service Composition Architecture (Arquitetura de Composição de Serviços) – Arquitetura de serviços que pertençam a composição de outros serviços;

Service Inventory Architecture (Arquitetura de Inventário de Serviços) – Modelo que suporta uma coleção de serviços relacionados que são independentemente padronizados e administrados;

Service-Oriented Enterprise Architecture (Arquitetura Orientada a Serviços Empresariais) – Suas funcionalidades são tipicamente empresariais, seus padrões são muito relacionados, sendo que a modelagem de cada um requer uma atenção diferente daquela dispensada aos demais, além da documentação.

"Cada padrão é como um pedaço da sabedoria resultante do julgamento e de erros de engenheiros que trabalham com projetos SOA (…) Este catálogo de padrões é muito mais que o resultado de um esforço de uma comunidade. Experts da indústria de desenvolvimento contribuíram com padrões para este catálogo, e padrões foram o assunto para a abertura de uma nova comunidade(…)" (Erl, 2008, p. 7)

4 – Catálogo Security

Joseph Yoder e Jeffrey Barcalow escreveram seu primeiro artigo sobre padrões de segurança em 1997. Eles descreveram uma variedade de padrões aplicáveis em diferentes aspectos de segurança. Foram utilizados exemplos do GOF para descrição de aspectos de segurança e para construção de estruturas para seus padrões. (Schumacher, 2006, p. 30)

Um padrão de segurança descreve um problema recorrente pertencente a um contexto específico e que possui uma solução genérica e testada. Cada solução consiste em um conjunto de regras que podem ser utilizadas na resolução de um problema concreto de segurança. (Schumacher, 2006, p. 31)

Desde o ano de seu primeiro lançamento até os dias de hoje, o catálogo Security acumulou um total de 46 padrões, como demonstrado na tabela abaixo:

Espero que tenham gostado, veremos mais Design Patterns por aqui.
Obrigado e []s!

Por
Fernando Henrique Inocêncio Borba Ferreira
Microsoft Most Valuable Professional – Data Platform Development

 

Referências:

GoF – HELM, Richard; VLISSIDES, John; JOHNSON , Ralph; GAMMA , Erich; Design Pattern – elements of reusable object-oriented software; BookMan; 1995.

FREEMAN, Eric, FREEMAN, Elisabeth; Head First – Design Patterns; O’Reilly Media;  Editora Alta Books Ltda; 2ª Edição Revisada; 2005.

SUN; Exploring the Model View Controller (MVC) Design Pattern; SUN Academic Initiative; SAI Leraning Connection; Java SE Application Development: Introduction; 2009; Acessado em 31 de Maio de 2009.

GRAND, Mark; Patterns in Java; Volume 1; 2ª Edição; Editora Wiley; 2002.

SILVA, Camillo de Lellis Falcão da; ARAUJO, Marco Antônio Pereira; Aplicando Padrões de Projeto na prática; Revista .Net Magazine; Editora DevMedia; Edição 54; Ano 5; 2008.

OLIVEIRA, Eric C M; Introdução a Design Patterns; http://www.linhadecodigo.com.br/Artigo.aspx?id=345; 07 de Junho de 2004; Acessado em 14 de Março de 2009.

ALEXANDRESCU, Andrei;  Modern C++ Design – Generic Programming and Design Pattern Applied; Addison-Wesley; 2001.

LARMAN, Craig; Applying UML and patterns: an introduction to object-oriented analysis and design and the unified process; BookMan; 2004.

FREITAS, Juliano Baldez de; Desenvolvimento Orientado a Objetos e Componentes; FAQI – Faculdade de Tecnologia de Gravataí; Tecnologia em Desenvolvimento de Sistemas;  http://www.escolaqi.com.br/professor; Acessado em 11 de Abril de 2009.

SANTOS, Wallace; Trabalhando com Padrões de Projeto – Design Patterns; Revista Mundo .Net; Editora Mundo; Número 13; Fevereiro/Março; Ano III; 2009.

ERL, Thomas; Introducing SOA Design Patterns; SOA World Magazine; Volume 8; Número 6; Junho; 2008.

SCHUMACHER, Markus; BUGLIONI, Fernandez Eduardo; HYBERTSON, Duane; BUSHMANN, Frank; SOMMERLAD, Peter; Secutiry Patterns: Integrating Security and Systems Engineering; John Wiley & Sons Ltd; 2006.