Introdução
Desenvolver software orientado a objetos é por si só um enorme desafio. Entretanto, desenvolver software orientado a objetos que sejam reusáveis é um desafio ainda maior! Você deve estar se perguntando, mas por que é tão difícil? É difícil por que existem muitas questões envolvidas em um bom projeto de objetos que seja reusável: devo usar métodos construtores ou uma fábrica de instâncias, devo usar herança ou agregação, a partir de quando o acoplamento entre as classes passa a ser nocivo, dentre outras questões. Mas há ainda um outro obstáculo a ser ultrapassado por muitos: a mudança do paradigma procedural para orientado a objetos.
Talvez, num futuro não muito distante, perguntem-nos: "Como era possível desenvolver aplicativos sem utilizar objetos?"; da mesma maneira que muitos se perguntam: "Como era possível desenvolver software de maneira não estruturada ?".
Tem um ditado popular que diz mais ou menos assim: “crie seu primeiro projeto para o seu inimigo, o segundo para o amigo e o terceiro para você”.
Exageros à parte, o primeiro projeto é sempre mais crítico, já que existe a necessidade de se desenvolver a partir do nada. No segundo, alguns objetos que foram pensados e usados no primeiro podem ser (re)utilizados, com algumas adequações. No terceiro, podem ser utilizados objetos do primeiro e do segundo. Assim, conforme vamos desenvolvendo mais projetos Orientados a Objetos, a produtividade e a qualidade do código melhoram substancialmente, graças à experiência adquirida e ao chamado “reaproveitamento de código” .
Isto ocorre porque, normalmente, todos os projetos envolvem a resolução de problemas recorrentes; não raras vezes nos pegamos com a sensação de ‘déjà vu‘. Este conhecimento, de como se resolver um determinado problema, acumulado durante os anos, é o que chamamos de experiência, e esta experiência está ligada diretamente aos responsáveis pela resolução do problema. Mas como podemos armazenar esta experiência para outros usos, ou então para o auxílio de outros desenvolvedores?
Se pudéssemos catalogar as experiências bem sucedidas de forma que qualquer pessoa, experiente ou não, pudesse utilizá-la para resolver problemas de desenvolvimento, conseguiríamos um grande aumento na qualidade dos projetos e uma redução sistemática nos tempos de desenvolvimento dos sistemas. Padrões de projeto têm justamente essa finalidade: catalogar, documentar e repassar soluções para problemas recorrentes.
Histórico
Considera-se como o início da história dos padrões de projeto a publicação de outra obra A Pattern Language: Towns, Buildings, Construction [1], de Christopher Alexander, em 1987. Durante anos, os especialistas na área de engenharia de software tentaram adequar as idéias de Alexander para a construção de sistemas de informação. Entretanto, a sua popularização só veio oito anos depois, em 1995, com o livro Design Patterns – Elements of Reusable Object-Oriented Software [3], também conhecido como GoF(Gang of Four), de Erich Gamma et al.
Hoje, além dos padrões GoF existem muitos outros padrões catalogados dentre eles podemos citar: padrões JEE, padrões GRASP e uma outra infinidade deles. O Pattern Almanac 2000 [5] lista cerca de 500 padrões de projeto, mas muitas centenas foram publicadas desde então. Porém, apesar de ser importante o conhecimento de um grande número de padrões, é ainda mais útil entender seus temas básicos subjacentes [4] (Coesão Alta, Acoplamento Baixo...) para ajudar na aprendizagem dos detalhes e do “alfabeto” fundamental das técnicas de projeto aplicadas.
REFERÊNCIAS BIBLIOGRÁFICAS
[1] ALEXANDER C., S. et al. A pattern language : towns buildings construction. Oxford University Press, 1977.
[2] FLOWER, Martin. Analysis patterns : reusable object models. Reading : Addison-Wesley, 1997.
[3] GAMMA, Erich et al. Design patterns: elements of reusable object-oriented software. Reading : Addison-Wesley, 1994.
[4] LARMAN C. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. 1.ed. Estados Unidos da América: Prentice Hall, 2004.
[5] RISING, L. 2000. Pattern Almanac 2000. Reading, MA.: Addison-Wesley.
