Introdução a Design Patterns

No artigo dessa semana, estaremos abordando os design patterns, ou padrões de modelagem, que podem ser definidos como soluções já testadas para problemas de modelagem que ocorrem com freqüências em situações específicas. Um assunto que interessa tanto as comunidades Java ou .NET.

por Eric C M Oliveira

No artigo dessa semana, estaremos abordando os design patterns, ou padrões de modelagem, que podem ser definidos como soluções já testadas para problemas de modelagem que ocorrem com freqüências em situações específicas. Um assunto que interessa tanto as comunidades Java ou .NET.

Como várias abordagens referentes a engenharia de software, os design patterns tiveram suas raízes no trabalho do engenheiro civil Chistopher Alexander, que redigiu sobre as suas experiências em resolver problemas de projetos encontrados em construções em geral. Segundo o próprio Christopher, "cada pattern descreve um problema que ocorre com freqüência em nosso ambiente, e então descreve o núcleo da solução para tal problema, de uma maneira que possamos utilizar esta solução milhares de vezes".

Os princípios de Alexander foram trazidos para o desenvolvimento de software, que culminou na publicação da obra "Design Patterns: Elements of Reusable Object-Oriented Software", de 1995 por Eric Gamma, Richard Helm, Ralph Johnson e John Vlissides. Este livro é considerado a principal referência de design patterns para a comunidade de software e tem influenciado na evolução dos padrões de projeto desde então. A obra descreveu 23 padrões baseados na experiência dos autores. Muitos outros padrões foram documentados e catalogados desde a publicação de Design Patterns. Entretanto, esses 23 iniciais são provavelmente os mais populares.

Em termos de documentação, os design patterns são altamente estruturados.Eles são documentados a partir de um modelo que identifica a informação necessária para entender o problema do software e a solução em termos de relacionamentos entre as classes e objetos necessários para implementar essa solução. Não há um ponto comum na comunidade de design patterns sobre como descrever um template de patterns. Alguns autores preferem ser mais expressivos e menos estruturados, enquanto outros preferem que seus templates sejam mais precisos e altamente estruturados.

A UML tem papel importante nessa documentação. É comumente usada para descrever patterns e cataloga-los, incluindo diagrama de classes, de seqüência ou de interações. Abaixo um exemplo de um diagrama de seqüência do pattern MVC:

Segue abaixo um template de um Design Pattern:

Nome Padrão [Descreve a essência do padrão em um curto e expressivo nome].
Objetivo [Descreve o que o padrão faz].
Também Conhecido Como [Lista de sinônimos para o padrão].
Motivação [Fornece um exemplo de um problema e como o padrão resolve aquele problema].
Aplicabilidade [Lista as situações onde o padrão é aplicado].
Estrutura [Conjunto de diagramas de classes e objetos que descrevem o padrão].
Participantes [Descreve as classes e objetos que participam do design pattern e suas responsabilidades].
Colaborações [Descreve como os participantes colaboram para cumprir com suas responsabilidades].
Conseqüências [Descreve os benefícios e os custos da utilização do padrão].

Raramente um pattern é utilizado isoladamente. Tipicamente, os patterns tem relacionamentos e trabalham em conjunto. Quanto mais familiarizado com os diferentes tipos de design patterns, melhor instruído se estará para determinar interações entre esses componentes.

Como exemplo de aplicações em camadas com uso de componentes, existem quatro patterns específicos, com características de melhora de performance de um sistema e facilidade de manutenção. São eles MVC, DAO, DTO e Session Façade.

Um dos mais usados nos dias de hoje é o design pattern MVC, que permite que se separe o modelo de dados das várias formas que o dado possa ser acessado e manipulado. Um sistema MVC é dividido em um modelo de dados, um conjunto de visões e um conjunto de controladores. Na verdade existem quatro componentes em uma aplicação MVC, não três, já que o cliente é uma parte integrante de toda a operação. Desacoplar as visões do processo de requisição torna mais fácil criar novas visões para novos formatos. Uma aplicação poderia apresentar uma interface HTML e depois adicionar visões WML (para dispositivos wireless) e visões XML (para Web services) futuramente.

Os patterns também não devem ser encarados como uma "bala de prata". Deve-se ter a consciência de que apenas porque um problema é observado e um pattern é aplicado, não se deve imaginar que se tem em mãos uma perfeita aplicação ou solução para o problema aplicado. Devemos encara-los como um caminho para trazer clareza para uma arquitetura de um sistema, além de permitir possibilidades de melhora nesse determinado sistema.