Explicando Padrões de Projeto

No fim da década de 70, um arquiteto chamado Christopher Alexander levantou questões sobre o que determina a qualidade de um projeto de construção bem elaborado. Procurou por padrões que poderiam ser considerados como boas práticas por todos os outros arquitetos. Durante este trabalho, levantou uma série de interessantes questões: como posso determinar se um projeto é realmente bom? Há uma base objetiva para o julgamento? Essa base descreve um senso comum?

Em seu trabalho Alexander concluiu que seria possível desenvolver uma base objetiva para os projetos, e tal base seria considerada adequada pelo senso comum. Estipulou que um bom projeto não era baseado simplesmente no gosto do arquiteto. Para o autor, essa base poderia ser descrita e mensurada.

Alexander saiu a campo e fez observações em diferentes tipos de construções: prédios, ruas, varandas etc. Neste trabalho de observação descobriu que, para um tipo particular de arquitetura, todas as boas construções possuíam semelhanças entre si. Os projetos, apesar de suas individualidades, apresentavam técnicas em comum. Então, registrou essas técnicas comuns, definiu nomes e as características de cada uma delas, montando um catálogo de padrões.

Na conclusão do trabalho, Alexander postulou que padrões poderiam resolver, em tese, muito dos tipos de problemas de arquitetura encontrados. Também promoveu a idéia que os padrões poderiam ser utilizados em conjunto para solver problemas complexos de arquitetura.

No início da década de 90, quatro amigos tomaram conhecimento do trabalho de Alexander e buscaram fazer o mesmo para o desenvolvimento de software: criar padrões baseados em boas soluções de código. Os programadores seguiram os passos do arquiteto, foram a campo e levantaram padrões que eram utilizados da mesma forma em diversos tipos de projetos de software. O resultado foi um novo catálogo de padrões de projeto (design patterns), desta vez, projetos de software. Os quatro amigos (Gamma, Helm, Johnson, & Vlissides) tornaram-se mundialmente conhecidos como GoF – Gang of Four – e o catálogo dos padrões se tornou a obra de referência para o estudo de padrões de projeto.

Este é o primeiro artigo de uma série com o objetivo de explicar padrões de projeto. Nessa edição serão abordados os principais conceitos de padrões de projeto e dois desses padrões: Adapter e Singleton.

Padrões de Projeto

Um padrão de projeto determina nomes, motivações e expõe soluções voltadas para um problema recorrente em sistemas orientados a objeto. O padrão deve descrever o problema, a solução e em que caso a solução pode ser aplicada, além das conseqüências na adoção do mesmo. O padrão também deve ser ilustrado com exemplos e dicas de implementação. A solução é baseada em uma organização geral de classes e objetos voltados para resolver um determinado problema.

A tradução “Padrão de projeto”, apesar de correta, é algo enganosa, pois em português o sentido mais comum de “padrão” é o de um modelo rígido de referência, norma, regra a ser seguida de forma exata – ou seja, o que os americanos chamam de “standard”. Lembre sempre que o “pattern” de design pattern tem o sentido mais flexível de modelo, estilo, configuração geral... como as expressões regulares, que podem reconhecer inúmeros textos muito diferentes, porém com certas semelhanças fundamentais (também nesse exemplo, em inglês usa-se “pattern matching”, com o sentido mais soft de pattern.)

Cada padrão é uma regra de três partes que expressa a relação entre um contexto, um problema e uma solução. Sendo assim, para entender um padrão precisamos estudar suas partes: o problema, a solução e o contexto onde é aplicável. Sem o contexto não é possível determinar qual padrão de projeto aplicar. Em Orientação a Objetos, os problemas costumam ser representados por criação de objetos, estruturação de classes, modos de acesso a dados, formas de trocas de mensagem e outros que enfrentamos de maneira semelhante em diversos sistemas. Tendo o problema definido, precisamos analisar o contexto que ele se manifesta; alguns fatores relacionados ao ambiente, como requisitos não-funcionais, podem determinar se um dado padrão de projeto é aplicável.

Catálogo de Padrões de Projeto

Os padrões costumam ser encontrados em catálogos voltados para os contextos e o tipo de problema aos quais se aplicam. Os principais trabalhos são:

Design Patterns: Elements of Reusable Object-Oriented Software

É a obra de referência em padrões de projeto. Outros catálogos citam referências ao catálogo GoF e seguem o mesmo estilo de apresentação dos padrões. No total são apresentados 23 padrões, segmentados em padrões de criação (creational patterns), padrões de estrutura (structural patterns) e padrões de comportamento (behavioral patterns), como pode ser visto na Tabela 1.

Core J2EE Design Patterns: Best Practices and Design Strategies, 2nd. ed. ...