Origens

A idéia dos padrões, como é aplicada ao design de software, vem do trabalho de Christopher Alexander. Ele escreveu extensamente sobre a aplicação de padrões ao design e à construção de cidades e edifícios. Dois de seus livros, A Pattern Language [ALE77] e The Timeless Way of Building [ALE79] tiveram grande impacto na comunidade de software e na adoção dos padrões de software para o design de software. Seus conceitos de padrões e da linguagem de padrão fornecem um modelo para a captura do design de software de forma que possa ser reaplicado em situações recorrentes.

Uma definição de padrões

Atualmente, A definição normalmente mais usada para padrões de software vem de [GAM95]:

"Um padrão de design descreve o problema, uma solução para o problema que consiste em um arranjo geral de objetos e classes, o momento de aplicar a solução e as conseqüências da aplicação da solução."

Normalmente esta definição só serve como um ponto de partida. Entretanto, uma definição mais rica, baseada no trabalho de Alexander, é oferecida por Gabriel em seu livro, A Timeless Way of Hacking [ALU03], em que cada padrão é uma regra de três partes que expressa os relacionamentos entre um determinado contexto, um determinado sistema de forças que ocorrem repetidamente nesse contexto e uma determinada configuração de software que permita que estas forças se resolvam.

Descrevendo padrões

É comum descrever padrões usando o formato popular criado por Erich Gamma e seus três colegas [GAM95]. Eles ficaram conhecidos como a Gangue dos Quatro (GoF); conseqüentemente, sua descrição ficou conhecida como formato GoF. O formato GoF usa as seguintes palavras-chave para descrever os padrões de projeto orientados a objeto:

• Nome e classificação do padrão: Nomear o padrão permite que o design trabalhe em um nível mais elevado de abstração, usando um vocabulário de padrões. Gamma diz que encontrar um bom nome é um dos problemas mais difíceis de resolver no desenvolvimento de um catálogo de padrões (veja Pattern catalogues nesta seção).

• Intenção: Resposta para perguntas, tais como: O que o padrão faz? Para qual problema ele é indicado?

• Também conhecido como: Outros nomes para o padrão.

• Motivação: Um cenário concreto que ilustra um problema de design e como o padrão resolve o problema.

• Aplicabilidade:Instruções para o reconhecimento das situações onde os padrões são aplicáveis..

• Estrutura: Uma representação gráfica das classes no padrão.

• Participantes: As responsabilidades das classes e dos objetos que participam no padrão.

• Colaborações: Como os participantes colaboram para cumprir suas responsabilidades.

• Conseqüências: Os resultados, efeitos colaterais e perdas causadas pelo uso do padrão.

• Implementação: Orientação na implementação do padrão.

• Código de exemplo: Fragmentos de código que ilustram a implementação do padrão.

• Usos conhecidos: Onde encontrar exemplos do mundo real sobre a utilização do padrão.

• Padrões relacionados: Sinergias, diferenças e outros relacionamentos do padrão.

Embora o formato GoF seja especificamente direcionado para o desenvolvimento orientado a objeto, você pode usá-lo, com poucas modificações, para tratar outros padrões de software. Um formato de palavras-chave mais geral para os padrões de software baseado nos princípios de Alexander usa as palavras-chave problema, contexto, forças e solução.

Catálogos de padrões

Para ajudar na identificação e seleção de padrões, vários esquemas de classificação foram propostos. Um dos esquemas mais recentes, proposto por Buschmann e seus associados, [BUS96] usa três classificadores: granularidade, funcionalidade e princípios estruturados. Destes três classificadores, a granularidade tornou-se popular. A Granularidade classifica os padrões em três níveis de abstração:

• Padrões Arquiteturais: Os padrões arquiteturais expressam a estrutura fundamental de um esquema de software. Alguns exemplos de padrão arquitetural são: Camadas (layers), pipes e filtros e o padrão modelo visão controle (MVC).

• Padrões de design: A arquitetura de software normalmente consiste de pequenas unidades arquiteturais que são descritas por padrões de design. O padrão GoF é um exemplo de padrão de design.

• Idiomas: Um idioma é um padrão de mais baixo nível e é específico para uma linguagem de programação.

Buschmann e seus colegas introduziram quatro grupos para categorizar padrões arquiteturais:

• Estrutura
• Sistemas distribuídos
• Sistemas interativos
• Sistemas Adaptáveis

A tabela a seguir mostra a categorização de seus padrões arquiteturais.

Para padrões de design, o grupo de Gamma categorizou seus padrões de design pela finalidade, usando três categorias:

• Criativo
• Estrutural
• Comportamental

Linguagens de padrão

Além do conceito de padrões, Alexander deu também à comunidade de software o conceito de uma linguagem de padrão. A finalidade de desenvolver uma linguagem de padrão era fornecer um vocabulário de princípios de design (padrões) que permitiriam para aqueles que trabalham, estudam ou vivem em construções, comunicar-se eficazmente com os arquitetos e os projetistas dessas construções. Alexander explica isso ao usar uma linguagem de padrão:

Nós sempre a usamos como uma seqüência, passando através dos padrões, movendo-se sempre dos padrões maiores para os menores, sempre dos que criam a estrutura para os que embelezam estas estruturas, e então para àqueles que embelezam os embelezamentos.

Ao aplicar os padrões desta forma, Alexander advogou o uso das linguagens geradoras do padrão, aquelas que, dado um contexto inicial, sempre conduziriam a um design. Alexander declarou:

Assim, como no caso das linguagens naturais, a linguagem de padrão é geradora. Ela não só nos diz quais são as regras de arranjo, mas nos mostra como construir os arranjos - tantos quantos nós quisermos - que satisfaçam as regras.

Na aplicação de padrões de software, os nomes dos padrões fornecem um vocabulário para a comunicação das idéias de software. A aplicação seqüencial dos padrões encontra uso nos processos de design de software, tanto iterativo quanto em cascata, que aplicam sucessivamente padrões arquiteturais, padrões de design e, finalmente, idiomas para projetar e implementar um sistema de software. Os processos de software, entretanto, dependem muito mais das habilidades do Arquiteto e do Desenvolvedor para guiar a aplicação dos padrões do que de uma linguagem geradora de padrão.