Desenvolver software é algo complicado. É necessário compreender de tecnologia , do negócio do cliente, e ainda ser ajuizado o suficiente para manter todo o conhecimento ali produzido documentado da melhor maneira possível, para que outros possam continuar o projeto.
Uma das formas de documentação do conhecimento produzido em um processo de desenvolvimento de software que surgiu naturalmente como iniciativa comunitária, foram os padrões de projeto. E o que são padrões de projeto? Existem algumas definições as quais podemos recorrer:
Def. 1: (GoF) Um padrão de projeto sistematicamente nomeia, motiva e explica um projeto genérico, que endereça um problema de projeto recorrente em sistemas orientados a objetos. Ele descreve o problema, a solução, quando é aplicável e quais as conseqüências do seu uso. Def.2: (Coplien) Um padrão (de projeto) é uma peça de literatura que descreve um problema de projeto e a solução geral para o problema em um contexto particular. Def.3: (Budinsky, Finnie, Vlissides e Yu) Padrões de projeto capturam a experiência na construção de software orientado a objetos.Budisky et al. põem uma importância enorme aos padrões de projeto na sua definição. Capturar a experiência é algo naturalmente difícil e extremamente útil.
Mas, como surgiram os padrões de projetos para a computação? Isso nos leva ao ano de 1987, quando Ward Cunninghan e Kent Beck propuseram (implementados em Smalltalk) os primeiros 5 padrões e os apresentaram na OOPSLA. Num trabalho paralelo a sua tese de doutorado, Eric Gamma nota a importância dos padrões repetitivos em projetos, levando o tema a discussão em conferência integrada da OOPSLA e ECOOP em 1990, junstamente com Bruce Anderson e Richard Helm. A partir de então, o tema ganha mais importância, com a prublicação de livros como “Advanced C++ Programming Styles and Idioms” (Coplien, 1992), ou “Design Patterns: Elements of reusable object-oriented software” da gangue dos quatro (1995) e vários outros.
Existem alguns critérios para que uma solução torne-se um padrão:
- Devem descrever e justificar as soluções para problemas concretos e bem definido, i.e., não são estratégias ou princípios de implementação;
- As soluções descritas devem estar comprovadas, i.e., devem ter sido previamente experimentadas e testadas;
- O problema tratado por um padrão deve ocorrer em diferentes contextos, ou seja, se a solução não tem aplicação em diferentes situações, então não é um padrão;
- Usualmente os padrões de projeto descrevem relações entre os conceitos, mecanismos e estruturas existentes nos sistemas;
- Os padrões de projeto devem ser capazes de capturar a evolução e o aprimoramento das soluções, assim como equilibrar os pontos fortes e fracos encontrados, sendo assim, não são soluções óbvias ou triviais;
- Os padrões devem ser utilizados em conjunto com outros padrões, compondo uma linguagem de padrões.
Podemos dividir os padrões em três categorias:
- Padrões de Criação: Ligados ao processo de instanciação;
- Padrões Estruturais: Observam as formas de composição dos objetos e/ou classes;
- Padrões Comportamentais: Observam a maneira com que classes e objetos podem interagir.
O que vou fazer aqui é descrever e comentar um pouco sobre os padrões que conheço e/ou mais populares, acrescentando códigos em Java (talvez em C++) para ilustrar a utilização.
É importante notar que os padrões não são o grande canivete suíço que resolverá todos os seus problemas, mas constituem uma ferramenta extra muito útil nas situações do dia-a-dia, e certamente facilitará a vida de quem os conhece.
À medida que for comentando os padrões, colocarei seus links neste artigo, que servirá como índice e introdução ao tema.
