Padrões de projeto (em inglês, Design Patterns) são soluções para problemas específicos que ocorrem de forma recorrente em um determinado contexto que foram identificados a partir da experiência coletiva de desenvolvedores de software.
A proposta original de padrões veio do trabalho de Christopher Alexander na área de arquitetura. Sua definição para padrões é que "Cada padrão é uma regra (esquema) de três partes que expressa uma relação entre um certo contexto, um problema, e uma solução".
O contexto descreve uma situação no desenvolvimento na qual existe um problema. O problema que ocorre repetidamente no contexto deve também ser descrito bem como as forças (requisitos, restrições e propriedades) associadas a ele. A solução descreve uma configuração ou estrutura de componentes e suas interconexões, obedecendo às forças do problema. As forças, denominação dada por Alexander, descrevem:
- os requisitos que caracterizam o problema e que a solução deve satisfazer,
- as restrições que devem ser aplicadas às soluções
- as propriedades desejáveis que a solução deve ter.
Exemplo: Observer (Observador)
Considere uma interface gráfica que permita representar uma estrutura de dados de diversas formas - tabela, gráfico de barras e gráfico de tortas. A solução mais simples é ativar cada uma das classes que implementam as três diferentes visualizações cada vez que a estrutura de dados for ativada. Isso, no entanto, torna o núcleo do software dependente da interface (maior acoplamento). Além disso, para adicionar novas visualizações, é preciso modificar também a estrutura de dados.
Um bom design de software requer um única estrutura de dados independente das três diferentes visualizações e atuando como observadores. Para isso, é preciso que a implementação das visualizações sejam observadores (ouvintes) da estrutura de dados e que sejam avisados quando ocorrer um evento de atualização.
O padrão Observer oferece uma solução para isso:
- Contexto: Situações nas quais vários componentes dependem de dados que são modificados em outro componente (sujeito).
- Problema: Os dados do componente sujeito modificam-se constantemente e precisam ser atualizados nos outros componentes. O número de componentes pode variar.
- Solução: Utilizar um mecanismo de registro que permite ao componente sujeito notificar aos interessados sobre mudanças.
A visualização das classes e a interação dos objetos são ilustrados na figura abaixo.
Para saber mais:
Pattern-Oriented Software Architecture (POSA) – A System of Patterns – F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal John Wiley and Sons Ltd, Chichester, UK, 1996
Comentários