O que é Design Patterns?

Uma das definições mais conhecidas é a de que um padrão [b]"é uma solução para um problema em um contexto"[/b] [GoF95]. Apesar de não estar errada, esta definição é simplista e incompleta. Em [GoF95], os autores contextualizam esta afirmação, completando-a. Porém, muitas vezes esta definição apresentada isolada, passando uma idéia incorreta. Para uma definição melhor, devemos entender o que são o contexto, o problema e a solução: - [b]Contexto[/b] se refere a um conjunto de situações nas quais o padrão se aplica [LeaFAQ]. Exemplo: "Processamento de fluxos de dados." - [b]Problema[/b] se refere a um conjunto de forças - objetivos e limitações - que ocorrem neste contexto [LeaFAQ]. Exemplo: "Aprimoramentos futuros devem ser possíveis por recombinação dos elementos; Segmentos não adjacentes não compartilham dados; etc." - [b]Solução[/b] se refere à forma canônica ou regra do projeto, que podemos aplicar para resolver estas forças [LeaFAQ]. Exemplo: "Dividir a tarefa em vários passos seqüenciais, conectados pelo fluxo de dados do sistema (...)." Além de apresentar o contexto e resolver o problema, faltam pelo menos três coisas: - [b]Repetição[/b], que faz a solução relevante em situações além da apresentada [Vlis97]. - [b]Explicação[/b], que nos dá o conhecimento para adaptar a solução a variantes do problema. As explicações nos padrões reais geralmente se situam na descrição e resolução de forças e/ou conseqüências da aplicação [Vlis97]. - Um [b]nome[/b] pelo qual podemos nos referir ao padrão [Vlis97]. Padrões criam um [b]vocabulário comum[/b] aos desenvolvedores, que usam os nomes dados como termos abstratos ao se referir a construções representadas por eles. Por exemplo, ao invés de explicar como uma classe-filha finge ser e contém sua classe-pai, delegando suas funções a ela e acrescentando função de cache, poderia-se simplesmente dizer que as classes se relacionam pelo padrão [i]Proxy[/i] [GoF95], com política de cache. A compactação da frase não omite informação alguma, nem simplifica demais a situação. Pelo contrário, ela facilita o entendimento usando um conhecimento adquirido referenciado por um nome. É comum, porém, o erro de se pensar em padrões como simplesmente [i]jargões, regras, truques de programação ou estruturas de dados[/i]. Isso seria menosprezá-los. É natural tentar reduzir algo não familiar a algo conhecido, especialmente se não somos motivados a investigá-lo. Isto, freqüentemente, é baseado em familiaridade superficial e um pouco de cinismo, não em experiência [Vlis97]. Apesar de muitas vezes um padrão envolver todos estes outros conceitos, equipará-lo a apenas um deles seria simplificá-lo demais. Por outro lado, também é comum a crença de que padrões garantem reusabilidade, produtividade, ou de que geram arquiteturas completas. [b]Padrões não garantem nada[/b]. Pessoas os usam para buscar reusabilidade, produtividade e gerar arquiteturas. Os padrões não fazem nada para retirar o homem do processo criativo, apenas são um ferramenta a mais para uso do desenvolvedor [Vlis97]. Referências: [GoF95] GAMMA, Erich, HELM, Richard, JOHNSON, Ralph, VLISSIDES, John. Design Patterns: Elements of Reusable Software. 18. ed. Reading: Addison Wesley Longman, Inc. 1998. ISBN 0-201-63498-8 [LeaFAQ] LEA, Doug. Patterns-Discussion FAQ, na State University of New York. dez/2003, http://g.oswego.edu/dl/pd-FAQ/pd-FAQ.html [Vlis97] VLISSIDES, John. Patterns: The Top Ten Misconceptions. Object Magazine, March 1997.