No ano de 1987 a partir dos conceitos criados por Alexander, os programadores Kent Beck e Ward Cunningham propuseram os primeiros padrões de projetos para a área da ciência da computação. Eles apresentaram alguns padrões para a construção de aplicações comerciais em linguagem Smalltalk, isso durante um trabalho para a conferência OOPSLA. Nos anos seguintes Beck, Cunningham e outros seguiram com o desenvolvimento destas ideias.
O movimento ao redor de padrões de projetos só ganhou popularidade em 1995 quando foi lançado o livro Design Patterns: Elements of Reusable Object-Oriented Software. Os autores desse livro, Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, conhecidos como a Gangue dos Quatro (Gang of Four) ou simplesmente GoF.
Em Engenharia de Software um padrão de desenho ou padrão de projeto que vem do inglês Design Patterns que é uma solução geral para um problema que ocorre com frequência dentro de projeto de software e um determinado contexto. Um padrão de projeto não é um projeto finalizado que pode ser transformado diretamente em código fonte ou de máquina, ele é uma descrição ou um template de como resolver um problema que pode ser usado em várias situações diferentes. Um programador pode usar padrões que são melhores práticas formalizadas para resolver um problema comum quando projetado a uma aplicação ou sistema. Padrões de projeto orientados a objeto normalmente mostram relacionamentos e interações entre classes ou objetos, sem especificar os objetos ou as classes da aplicação final que estão envolvidas.
Projetos padrões residem no domínio de módulos e interconexões, em um nível mais alto que padrões arquiteturais são maiores em escopo, usualmente descrevendo um padrão global por um sistema inteiro.
4 Elementos do Design Patterns:
Nome
- Devem possuir um NOME, que descreva o problema, as soluções e consequências. Um nome permite definir o vocabulário a ser utilizado pelos projetistas e desenvolvedores em um nível mais alto de abstração.
Problemas
- Todo padrão deve relatar de maneira clara a qual (is) PROBLEMA (s) ele deve ser aplicado, ou seja, quais são os problemas que quando inserido em um determinado contexto o padrão conseguirá resolver. Alguns podendo exigir pré-condições.
Solução
- Solução descreve os elementos que compõem o projeto, seus relacionamentos, responsabilidades e colaborações. Um padrão deve ser uma SOLUÇÃO concreta, ele deve ser exprimido em forma de gabarito (algoritmo) que, no entanto, pode ser aplicado de maneiras diferentes.
Consequências
- – Todo padrão deve relatar quais são as suas CONSEQUÊNCIAS para que possa ser analisada a solução alternativa de projetos e para a compreensão dos benefícios da aplicação do projeto.
- Não pode ser considerado um padrão de projeto trecho de códigos específicos, mesmo que para o seu criador ele reflita um padrão, que soluciona um determinado problema, porque os padrões devem estar a um nível maior de abstração e não limitado a recursos de programação. Um padrão de projeto nomeia, abstrai e identifica os aspectos chaves de uma estrutura de projeto comum para torna-la útil para a criação de um projeto orientado a objetos reutilizável.
