Padrão de projeto de software: diferenças entre revisões
m Desfeita a edição 30121641 de 187.58.127.2 |
|||
Linha 134: | Linha 134: | ||
* {{Link|en|http://www.mindspring.com/~mgrand/pattern_synopses2.htm|Lista de alguns padroes comuns}} |
* {{Link|en|http://www.mindspring.com/~mgrand/pattern_synopses2.htm|Lista de alguns padroes comuns}} |
||
* {{Link|en|http://www.vincehuston.org/dp/|Página com descrições e exemplos dos padrões GoF}} |
* {{Link|en|http://www.vincehuston.org/dp/|Página com descrições e exemplos dos padrões GoF}} |
||
* {{Link|pt-br|http://delegadoanonimo.blogspot.com.br/2012/05/s01-e03-design-patterns.html|Podcast Delegado Anônimo sobre padrões GoF}} |
|||
{{Padrões de projeto}} |
{{Padrões de projeto}} |
Revisão das 14h17min de 14 de maio de 2012
Um Padrão de Projeto de Software ou Padrão de Desenho de Software, também muito conhecido pelo termo original em inglês, Design Pattern, descreve uma solução geral reutilizável para um problema recorrente no desenvolvimento de sistemas de software orientados a objetos. Não é um código final, é uma descrição ou modelo de como resolver o problema do qual trata, que pode ser usada em muitas situações diferentes. Os Padrões de Projeto normalmente definem as relações e interações entre as classes ou objetos, sem especificar os detalhes das classes ou objetos envolvidos, ou seja, estão num nível de generalidade mais alto.
Um padrão de projeto define :
- seu nome,
- o problema,
- a solução,
- quando aplicar esta solução e
- suas consequências.
Os padrões de projeto :
- visam facilitar a reutilização de soluções de desenho - isto é, soluções na fase de projeto do software - e
- estabelecem um vocabulário comum de desenho, facilitando comunicação, documentação e aprendizado dos sistemas de software.
História
Christopher Alexander[1][2][3] Em seus livros Notes on the Synthesis of Form, The Timeless Way of Building e A Pattern Language, ele estabelece que um padrão deve ter, idealmente, as seguintes características:
- Encapsulamento: um padrão encapsula um problema/solução bem definida. Ele deve ser independente, específico e formulado de maneira a ficar claro onde ele se aplica.
- Generalidade: todo padrão deve permitir a construção de outras realizações a partir deste padrão.
- Equilíbrio: quando um padrão é utilizado em uma aplicação, o equilíbrio dá a razão, relacionada com cada uma das restrições envolvidas, para cada passo do projeto. Uma análise racional que envolva uma abstração de dados empíricos, uma observação da aplicação de padrões em artefatos tradicionais, uma série convincente de exemplos e uma análise de soluções ruins ou fracassadas pode ser a forma de encontrar este equilíbrio.
- Abstração: os padrões representam abstrações da experiência empírica ou do conhecimento cotidiano.
- Abertura: um padrão deve permitir a sua extensão para níveis mais baixos de detalhe.
- Combinatoriedade: os padrões são relacionados hierarquicamente. Padrões de alto nível podem ser compostos ou relacionados com padrões que endereçam problemas de nível mais baixo.
Além da definição das características de um padrão, Alexander definiu o formato que a descrição de um padrão deve ter. Ele estabeleceu que um padrão deve ser descrito em cinco partes:
- Nome: uma descrição da solução, mais do que do problema ou do contexto.
- Exemplo: uma ou mais figuras, diagramas ou descrições que ilustrem um protótipo de aplicação.
- Contexto: a descrição das situações sob as quais o padrão se aplica.
- Problema: uma descrição das forças e restrições envolvidos e como elas interagem.
- Solução: relacionamentos estáticos e regras dinâmicas descrevendo como construir artefatos de acordo com o padrão, freqüentemente citando variações e formas de ajustar a solução segundo as circunstâncias. Inclui referências a outras soluções e o relacionamento com outros padrões de nível mais baixo ou mais alto.
Em 1987, a partir dos conceitos criados por Alexander, os programadores Kent Beck e Ward Cunningham propuseram os primeiros padrões de projeto para a área da ciência da computação. Em um trabalho para a conferência OOPSLA, eles apresentaram alguns padrões para a construção de janelas na linguagem Smalltalk.[4] Nos anos seguintes Beck, Cunningham e outros seguiram com o desenvolvimento destas idéias.
O movimento ao redor de padrões de projeto ganhou popularidade com o livro Design Patterns: Elements of Reusable Object-Oriented Software, publicado em 1995. Os autores desse livro, Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, são conhecidos como a "Gangue dos Quatro" (Gang of Four) ou simplesmente "GoF".
Posteriormente, vários outros livros do estilo foram publicados, merecendo destaque Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, que introduziu um conjunto de padrões conhecidos como GRASP (General Responsibility Assignment Software Patterns).
Padrões GoF
Os padrões "GoF" são organizados em 3 famílias :
- Padrões de criação : relacionados à criação de objetos
- Padrões estruturais : tratam das associações entre classes e objetos e
- Padrões comportamentais : tratam das interações e divisões de responsabilidades entre as classes ou objetos.
Padrões "GoF" organizados nas suas 3 famílias:
Padrões de criação
Padrões estruturais
Padrões comportamentais
Um padrão "GoF" também é classificado segundo o seu escopo em 2 outros grupos :
- Padrões com escopo de classe : definido por relacionamentos de herança e em tempo de compilação.
- Padrões com escopo de objeto : encontrados no relacionamento entre os objetos definidos em tempo de execução.
Padrões GRASP
Críticas
Segundo alguns, alguns 'Padrões de Projeto' são apenas evidências de que alguns recursos estão ausentes em uma determinada linguagem de programação (Java ou C++ por exemplo). Nesta linha, Peter Norvig demonstra que 16 dos 23 padrões do livro 'Design Patterns' são simplificados ou eliminados nas linguagens Lisp ou Dylan, usando os recursos diretos destas linguagens. [6]
Segundo outros, excessos nas tentativas de fazer o código se conformar aos 'Padrões de Projeto' aumentam desnecessariamente a sua complexidade. [7]
Bibliografia
- Christopher Alexander (1964). Notes on the Synthesis of Form. [S.l.]: Harvard University Press. ISBN 0-674-62751-2 Parâmetro desconhecido
|Autor=
ignorado (|autor=
) sugerido (ajuda); - Christopher Alexander (1979). The Timeless Way of Building. [S.l.]: Oxford University Press. ISBN 0-19-502402-8 Parâmetro desconhecido
|Autor=
ignorado (|autor=
) sugerido (ajuda); - Christopher Alexander (1977). A Pattern Language. [S.l.]: Oxford University Press. ISBN 0-19-501919-9 Parâmetro desconhecido
|Autor=
ignorado (|autor=
) sugerido (ajuda); - Craig Larman (2004). Applying UML and Patterns. An Introduction to Object-Oriented Analysis and Design and Iterative Development 1 ed. [S.l.]: Prentice Hall. ISBN 0-13-148906-2 Parâmetro desconhecido
|Autor=
ignorado (|autor=
) sugerido (ajuda); Parâmetro desconhecido|Páginas=
ignorado (|páginas=
) sugerido (ajuda) - Gregor Hohpe, Bobby Woolf (2004). Enterprise Integration Patterns. Designing, Building, And Deploying Messaging Solutions 1 ed. [S.l.]: Addinson-Wesley. ISBN 0-321-20068-3 Parâmetro desconhecido
|Autor=
ignorado (|autor=
) sugerido (ajuda); Parâmetro desconhecido|Páginas=
ignorado (|páginas=
) sugerido (ajuda) - Pablo Dall'Oglio (2007). PHP Programando com Orientação a Objetos. Inclui Design Patterns 1 ed. [S.l.]: Novatec. ISBN 978-85-7522-137-2 Parâmetro desconhecido
|Autor=
ignorado (|autor=
) sugerido (ajuda); Parâmetro desconhecido|Páginas=
ignorado (|páginas=
) sugerido (ajuda); Ligação externa em|Título=
(ajuda) - Alexandre Altair de Melo e Mauricio G. F. Nascimento (2007). PHP Profissional. Aprenda a desenvolver sistemas profissionais orientados a objetos com padrões de projeto 1 ed. [S.l.]: Novatec. ISBN 978-85-7522-141-9 Parâmetro desconhecido
|Autor=
ignorado (|autor=
) sugerido (ajuda); Parâmetro desconhecido|Páginas=
ignorado (|páginas=
) sugerido (ajuda); Ligação externa em|Título=
(ajuda)
Referências
- ↑ O conceito de padrão de projeto foi criado na década de 70 pelo arquitecto Christopher Alexander.
- ↑ Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1995). Design Patterns. Elements of Reusable Object-Oriented Software 1 ed. [S.l.]: Addison-Wesley. ISBN 0-201-63361-2 Parâmetro desconhecido
|Autor=
ignorado (|autor=
) sugerido (ajuda) - ↑ Doug Lea. «Christopher Alexander:An Introduction for Object-Oriented Designers» (em inglês). Consultado em 18 de abril de 2007
- ↑ Kent Beck, Ward Cunningham. «Using Pattern Languages for Object-Oriented Programs» (em inglês). Consultado em 18 de abril de 2007
- ↑ Utilizando UML e Padrões 2ª Edição - Craig Larman
- ↑ Norvig, Peter (1998). Design Patterns in Dynamic Languages
- ↑ McConnell, Steve (2004). Code Complete: A Practical Handbook of Software Construction, 2nd Edition. [S.l.: s.n.] p. 105