Mudanças entre as edições de "Design Pattern"
m (Criou página com 'Padrões de Projeto') |
m (→{{Ligações externas}}) |
||
| (Uma revisão intermediária pelo mesmo usuário não está sendo mostrada) | |||
| Linha 1: | Linha 1: | ||
| − | Padrões de | + | Os '''padrões de projeto de software''', também muito conhecido como '''''Design Patterns''''', descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de ''software'' orientados a objetos. Um padrão de projeto estabelece um nome e define o problema, a solução, quando aplicar esta solução e suas conseqüê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, sem considerar reutilização de código. Também acarretam um vocabulário comum de desenho, facilitando comunicação, documentação e aprendizado dos sistemas de ''software''. | ||
| + | |||
| + | == História == | ||
| + | O conceito de padrão de projeto foi criado na década de 70 pelo arquiteto Christopher Alexander. <ref>{{citar web|url=http://g.oswego.edu/dl/ca/ca/ca.html|titulo=Christopher Alexander:An Introduction for Object-Oriented Designers|autor=Doug Lea|língua=Inglês|acessodata=[[18 de abril]] de [[2007]]}}</ref> 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 [[Empirismo|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 [[programador]]es [[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 [[Smalltalk|linguagem Smalltalk]].<ref>{{citar web|url=http://c2.com/doc/oopsla87.html|titulo=Using Pattern Languages for Object-Oriented Programs|autor=Kent Beck, Ward Cunningham|língua=Inglês|acessodata=18 de abril de 2007}}</ref> 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 são [[Erich Gamma]], [[Richard Helm]], [[Ralph Johnson]] e [[John Vlissides]], conhecidos como a "Gangue dos Quatro" (Gang of Four) ou simplesmente "GoF". Posteriormente, vários outros livros do estilo foram publicados, como ''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 famílias de padrões: de criação, estruturais e comportamentais. Os padrões de criação são relacionados à criação de objetos, os estruturais tratam das associações entre classes e objetos e os comportamentais das interações e divisões de responsabilidades entre as classes ou objetos. | ||
| + | |||
| + | Um padrão "GoF" também é classificado segundo o seu escopo: de classe ou de objeto. Nos padrões com escopo de classe os relacionamentos que definem este padrão são definidos através de [[herança]] e em [[tempo de compilação]]. Nos padrões com escopo de objeto o padrão é encontrado no relacionamento entre os objetos definidos em [[tempo de execução]]. | ||
| + | |||
| + | Padrões "GoF" organizados nas suas famílias: | ||
| + | |||
| + | ==== Padrões de criação ==== | ||
| + | <div class="references" style="-moz-column-count:3; column-count:3;"> | ||
| + | * ''[[Abstract Factory]]'' | ||
| + | * ''[[Builder]]'' | ||
| + | * ''[[Factory Method]]'' | ||
| + | * ''[[Prototype]]'' | ||
| + | * ''[[Singleton]]'' | ||
| + | </div> | ||
| + | |||
| + | ==== Padrões estruturais ==== | ||
| + | <div class="references" style="-moz-column-count:3; column-count:3;"> | ||
| + | * ''[[Adapter]]'' | ||
| + | * ''[[Bridge (padrão de projeto de software)|Bridge]]'' | ||
| + | * ''[[Composite]]'' | ||
| + | * ''[[Decorator]]'' | ||
| + | * ''[[Façade]]'' | ||
| + | * ''[[Flyweight]]'' | ||
| + | * ''[[Proxy (padrões de projeto)|Proxy]]'' | ||
| + | </div> | ||
| + | |||
| + | ==== Padrões comportamentais ==== | ||
| + | <div class="references" style="-moz-column-count:3; column-count:3;"> | ||
| + | * ''[[Chain of Responsibility]]'' | ||
| + | * ''[[Command]]'' | ||
| + | * ''[[Interpreter]]'' | ||
| + | * ''[[Iterator]]'' | ||
| + | * ''[[Mediator]]'' | ||
| + | * ''[[Memento (informática)|Memento]]'' | ||
| + | * ''[[Observer]]'' | ||
| + | * ''[[State]]'' | ||
| + | * ''[[Strategy]]'' | ||
| + | * ''[[Template Method]]'' | ||
| + | * ''[[Visitor pattern|Visitor]]'' | ||
| + | </div> | ||
| + | |||
| + | == Padrões GRASP == | ||
| + | <div class="references" style="-moz-column-count:3; column-count:3;"> | ||
| + | * ''[[Controller]]'' | ||
| + | * ''[[Creator]]'' | ||
| + | * ''[[Expert (GRASP)|Expert]]'' | ||
| + | * ''[[Law of Demeter]]'' | ||
| + | * ''Low Coupling/High Cohesion'' | ||
| + | * ''[[Polymorphism]]'' | ||
| + | * ''[[Pure Fabrication]]'' | ||
| + | </div> | ||
Edição atual tal como às 22h40min de 1 de maio de 2011
Os padrões de projeto de software, também muito conhecido como Design Patterns, descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Um padrão de projeto estabelece um nome e define o problema, a solução, quando aplicar esta solução e suas conseqüê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, sem considerar reutilização de código. Também acarretam um vocabulário comum de desenho, facilitando comunicação, documentação e aprendizado dos sistemas de software.
Índice
História
O conceito de padrão de projeto foi criado na década de 70 pelo arquiteto Christopher Alexander. [1] 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.[2] 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 são Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, conhecidos como a "Gangue dos Quatro" (Gang of Four) ou simplesmente "GoF". Posteriormente, vários outros livros do estilo foram publicados, como 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 famílias de padrões: de criação, estruturais e comportamentais. Os padrões de criação são relacionados à criação de objetos, os estruturais tratam das associações entre classes e objetos e os comportamentais das interações e divisões de responsabilidades entre as classes ou objetos.
Um padrão "GoF" também é classificado segundo o seu escopo: de classe ou de objeto. Nos padrões com escopo de classe os relacionamentos que definem este padrão são definidos através de herança e em tempo de compilação. Nos padrões com escopo de objeto o padrão é encontrado no relacionamento entre os objetos definidos em tempo de execução.
Padrões "GoF" organizados nas suas famílias:
Padrões de criação
Padrões estruturais
Padrões comportamentais
Padrões GRASP
- Controller
- Creator
- Expert
- Law of Demeter
- Low Coupling/High Cohesion
- Polymorphism
- Pure Fabrication
