Padro de projeto de software

Origem: Wikipdia, a enciclopdia livre.

Orientao a objetos
Objeto / Instncia
Classe
Abstrao
Atributo
Mtodos
Mensagem
Encapsulamento
Herana / Herana mltipla
Associao
Polimorfismo
Interface
Outras referncias
Paradigma de programao
Padres de projeto
UML / RUP
Engenharia OO
v e
Em Engenharia de Software, um padro de desenho (portugus europeu) ou padro de
projeto (portugus brasileiro) (do ingls design pattern) uma soluo geral para
um problema que ocorre com frequncia dentro de um determinado contexto no projeto
de software. Um padro de projeto no um projeto finalizado que pode ser
diretamente transformado em cdigo fonte ou de mquina, ele uma descrio ou
modelo (template) de como resolver um problema que pode ser usado em muitas
situaes diferentes. Padres so melhores prticas formalizadas que o programador
pode usar para resolver problemas comuns quando projetar uma aplicao ou sistema.
Padres de projeto orientados a objeto normalmente mostram relacionamentos e
interaes entre classes ou objetos, sem especificar as classes ou objetos da
aplicao final que esto envolvidas. Padres que implicam orientao a objetos ou
estado mutvel mais geral, no so to aplicveis em linguagens de programao
funcional.

Padres de projeto residem no domnio de mdulos e interconexes. Em um nvel mais

alto h padres arquiteturais que so maiores em escopo, usualmente descrevendo um
padro global seguido por um sistema inteiro.[1]

Um padro de projeto define:

seu nome,
o problema,
quando aplicar esta soluo e
suas consequncias.
Os padres de projeto:

visam facilitar a reutilizao de solues de desenho - isto , solues na fase de

projeto do software - e
estabelecem um vocabulrio comum de desenho, facilitando comunicao, documentao
e aprendizado dos sistemas de software.
ndice [esconder]
1 Histria
2 Padres GoF ('Gang of Four')
2.1 Padres de criao
2.2 Padres estruturais
2.3 Padres comportamentais[3]
3 Padres [6][7][8]
3.1 Tipos de Padres Grasp
3.2 Information Expert
3.3 Creator
3.4 High Cohesion
3.5 Low Coupling
3.6 Controller
3.7 Polymorphism
3.8 Pure Fabrication
3.9 Indirection
3.10 Protected Variations
4 Crticas
5 Bibliografia
6 Referncias
7 Ligaes externas
Histria[editar | editar cdigo-fonte]
O arquiteto Christopher Alexander[2][3][4], em seus livros (1977/1979) Notes on the
Synthesis of Form, The Timeless Way of Building e A Pattern Language, estabelece
que um padro deve ter, idealmente, as seguintes caractersticas:

Encapsulamento: um padro encapsula um problema ou soluo bem definida. Ele deve

ser independente, especfico e formulado de maneira a ficar claro onde ele se
aplica.
Generalidade: todo padro deve permitir a construo de outras realizaes a partir
deste padro.
Equilbrio: quando um padro utilizado em uma aplicao, o equilbrio d a razo,
relacionada com cada uma das restries envolvidas, para cada passo do projeto. Uma
anlise racional que envolva uma abstrao de dados empricos, uma observao da
aplicao de padres em artefatos tradicionais, uma srie convincente de exemplos e
uma anlise de solues ruins ou fracassadas pode ser a forma de encontrar este
equilbrio.
Abstrao: os padres representam abstraes da experincia emprica ou do
conhecimento cotidiano.
Abertura: um padro deve permitir a sua extenso para nveis mais baixos de
detalhe.
Combinatoriedade: os padres so relacionados hierarquicamente. Padres de alto
nvel podem ser compostos ou relacionados com padres que endeream problemas de
nvel mais baixo.
Alm da definio das caractersticas de um padro, Alexander definiu o formato que
a descrio de um padro deve ter. Ele estabeleceu que um padro deve ser descrito
em cinco partes:

Nome: uma descrio da soluo, mais do que do problema ou do contexto;

Exemplo: uma ou mais figuras, diagramas ou descries que ilustrem um prottipo de
aplicao;
Contexto: a descrio das situaes sob as quais o padro se aplica;
Problema: uma descrio das foras e restries envolvidos e como elas interagem;
Soluo: relacionamentos estticos e regras dinmicas descrevendo como construir
artefatos de acordo com o padro, frequentemente citando variaes e formas de
ajustar a soluo segundo as circunstncias. Inclui referncias a outras solues e
o relacionamento com outros padres de nvel mais baixo ou mais alto.
Os patterns de Alexander procuravam prover uma fonte de ideias provadas para
indivduos e comunidades para serem usadas em construes, mostrando assim o quanto
belo, confortvel e flexvel os ambientes podem ser construdos.

Em 1987, a partir dos conceitos criados por Alexander, os programadores Kent Beck e
Ward Cunningham propuseram os primeiros padres de projeto para a rea da cincia
da computao. Em um trabalho para a conferncia OOPSLA, eles apresentaram alguns
padres para a construo de aplicaes comerciais em linguagem Smalltalk.[5] Nos
anos seguintes Beck, Cunningham e outros seguiram com o desenvolvimento destas
ideias.
Porm, o movimento ao redor de padres de projeto s ganhou popularidade em 1995
quando foi publicado o livro Design Patterns: Elements of Reusable Object-Oriented
Software. Os autores desse livro, Erich Gamma, Richard Helm, Ralph Johnson e John
Vlissides, so conhecidos como a "Gangue dos Quatro" (Gang of Four) ou simplesmente
"GoF".

Posteriormente, vrios 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 padres conhecidos como
GRASP (General Responsibility Assignment Software Patterns).

Padres GoF ('Gang of Four')[editar | editar cdigo-fonte]

De acordo com o livro: "Padres de Projeto: solues reutilizveis de software
orientado a objetos", os padres "GoF" so divididos em 23 tipos. Em funo dessa
grande quantidade de padres, foi necessrio classific-los de acordo com as suas
finalidades.

So 3 as classificaes/famlias:

Padres de criao: relacionados criao de objetos, visam abstrair o processo de

criao de objetos, ou seja, sua instanciao.
Padres estruturais: tratam das associaes entre classes e objetos, identificando
qual a melhor maneira de realizar o relacionamento entre as entidades.
Padres comportamentais: tratam das interaes e divises de responsabilidades
entre as classes ou objetos, facilitando a comunicao entre os objetos.
Padres "GoF" organizados nas suas 3 classificaes/famlias:

Padres de criao[editar | editar cdigo-fonte]

Abstract Factory
Builder
Factory Method
Prototype
Singleton
Padres estruturais[editar | editar cdigo-fonte]
Adapter
Bridge
Composite
Decorator
Faade (ou Facade)
Flyweight
Proxy
Padres comportamentais[3][editar | editar cdigo-fonte]
Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor
Existem outros critrios de classificao dos padres de projeto:

Finalidade: reflete o que um padro faz.

Escopo: especifica se o padro aplicado classe ou objeto.
Padres com escopo de classe: utilizam a hierarquia para compor ou variar os
objetos, mantendo a capacidade do sistema de se flexibilizar. Se realizarmos uma
comparao com o outro tipo de classificao isso costuma acontecer quando se trata
de um padro de criao.
Padres com escopo de objeto: encontrados no relacionamento entre os objetos
definidos em tempo de execuo. Realizando uma comparao com o outro tipo de
classificao vemos que esses padres aparecem muito nos padres estruturais e
comportamentais.
Padres [6][7][8][editar | editar cdigo-fonte]
Os padres GRASP, sigla para General Responsibility Assignment Software Patterns
(or Principles), consistem de um conjunto de prticas para atribuio de
responsabilidades a classes e objetos em projetos orientados a objeto.

Os padres GRASP (General Responsibility Assignment Software Patterns), so

responsveis pela descrio de princpios de fundamental importncia para a
atribuio de responsabilidades em projetos orientados a objetos, oferecendo um
melhor desempenho do cdigo, e trabalhando acerca de solucionar problemas,
garantindo melhor interface do projeto.

Sendo assim, importante sabermos que a qualidade do projeto orientado a objetos

est diretamente relacionada com a distribuio dessas obrigaes, que promovem a
no sobrecarga de objetos j que ocorre nesse processo a delegao de atividades,
ou seja, cada objeto ter uma funo especfica, de modo que, o que ele no souber
fazer ser repassado para o objeto que est mais preparado para fazer.

Todos esses padres servem para a resoluo de problemas comuns e bastante tpicos
de desenvolvimento de software orientado a objeto. Portanto, tais tcnicas apenas
documentam e normatizam as prticas j consolidadas, testadas e conhecidas no
mercado.

Os padres GRASP esto mais como uma ferramenta mental ou uma filosofia de design,
mas que ainda assim so teis para o aprendizado e desenvolvimento de um bom design
de software. Note que alguns padres GoF implementam solues correspondentes com
padres GRASP.

Tipos de Padres Grasp[editar | editar cdigo-fonte]

Dentro do GRASP podemos encontrar vrios padres relacionados aqueles de carter
bsicos e avanados.

Padres Bsicos:
Information Expert (ver Especialista na Informao);
Creator (ver Factory Method);
High Cohesion (ver Coeso);
Low Coupling(ver Acoplamento);
Controller(ver Model-view-controller).
Padres Avanados:
Polymorphism (ver Polimorfismo);
Pure Fabrication;
Indirection (ver Indireo);
Protected Variations (ver Variaes Protegidas).