Introduo a Design Patterns

No artigo dessa semana, estaremos abordando os design patterns, ou padres de modelagem, que podem ser definidos como solues j
testadas para problemas de modelagem que ocorrem com freqncias em situaes especficas. Um assunto que interessa tanto as
comunidades Java ou .NET.
por Eric C M Oliveira

No artigo dessa semana, estaremos abordando os design patterns, ou padres de modelagem, que podem ser definidos como
solues j testadas para problemas de modelagem que ocorrem com freqncias em situaes especficas. Um assunto que
interessa tanto as comunidades Java ou .NET.
Como vrias abordagens referentes a engenharia de software, os design patterns tiveram suas razes no trabalho do engenheiro
civil Chistopher Alexander, que redigiu sobre as suas experincias em resolver problemas de projetos encontrados em
construes em geral. Segundo o prprio Christopher, "cada pattern descreve um problema que ocorre com freqncia em nosso
ambiente, e ento descreve o ncleo da soluo para tal problema, de uma maneira que possamos utilizar esta soluo milhares
de vezes".
Os princpios de Alexander foram trazidos para o desenvolvimento de software, que culminou na publicao da obra "Design
Patterns: Elements of Reusable Object-Oriented Software", de 1995 por Eric Gamma, Richard Helm, Ralph Johnson e John
Vlissides. Este livro considerado a principal referncia de design patterns para a comunidade de software e tem influenciado na
evoluo dos padres de projeto desde ento. A obra descreveu 23 padres baseados na experincia dos autores. Muitos outros
padres foram documentados e catalogados desde a publicao de Design Patterns. Entretanto, esses 23 iniciais so
provavelmente os mais populares.
Em termos de documentao, os design patterns so altamente estruturados.Eles so documentados a partir de um modelo que
identifica a informao necessria para entender o problema do software e a soluo em termos de relacionamentos entre as
classes e objetos necessrios para implementar essa soluo. No h um ponto comum na comunidade de design patterns sobre
como descrever um template de patterns. Alguns autores preferem ser mais expressivos e menos estruturados, enquanto outros
preferem que seus templates sejam mais precisos e altamente estruturados.
A UML tem papel importante nessa documentao. comumente usada para descrever patterns e cataloga-los, incluindo
diagrama de classes, de seqncia ou de interaes. Abaixo um exemplo de um diagrama de seqncia do pattern MVC:

Segue abaixo um template de um Design Pattern:

Nome Padro [Descreve a essncia do padro em um curto e expressivo nome].
Objetivo [Descreve o que o padro faz].
Tambm Conhecido Como [Lista de sinnimos para o padro].
Motivao [Fornece um exemplo de um problema e como o padro resolve aquele problema].
Aplicabilidade [Lista as situaes onde o padro aplicado].
Estrutura [Conjunto de diagramas de classes e objetos que descrevem o padro].

Participantes [Descreve as classes e objetos que participam do design pattern e suas responsabilidades].
Colaboraes [Descreve como os participantes colaboram para cumprir com suas responsabilidades].
Conseqncias [Descreve os benefcios e os custos da utilizao do padro].
Raramente um pattern utilizado isoladamente. Tipicamente, os patterns tem relacionamentos e trabalham em conjunto. Quanto
mais familiarizado com os diferentes tipos de design patterns, melhor instrudo se estar para determinar interaes entre esses
componentes.
Como exemplo de aplicaes em camadas com uso de componentes, existem quatro patterns especficos, com caractersticas de
melhora de performance de um sistema e facilidade de manuteno. So eles MVC, DAO, DTO e Session Faade.
Um dos mais usados nos dias de hoje o design pattern MVC, que permite que se separe o modelo de dados das vrias formas
que o dado possa ser acessado e manipulado. Um sistema MVC dividido em um modelo de dados, um conjunto de vises e um
conjunto de controladores. Na verdade existem quatro componentes em uma aplicao MVC, no trs, j que o cliente uma
parte integrante de toda a operao. Desacoplar as vises do processo de requisio torna mais fcil criar novas vises para
novos formatos. Uma aplicao poderia apresentar uma interface HTML e depois adicionar vises WML (para dispositivos
wireless) e vises XML (para Web services) futuramente.
Os patterns tambm no devem ser encarados como uma "bala de prata". Deve-se ter a conscincia de que apenas porque um
problema observado e um pattern aplicado, no se deve imaginar que se tem em mos uma perfeita aplicao ou soluo
para o problema aplicado. Devemos encara-los como um caminho para trazer clareza para uma arquitetura de um sistema, alm
de permitir possibilidades de melhora nesse determinado sistema.

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

ve

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]

1Histria

2Padres GoF ('Gang of Four');

2.1Padres de criao

2.2Padres estruturais

2.3Padres comportamentais

3Padres GRASP
3.1Padres

4Crticas

5Bibliografia

6Referncias

7Ligaes externas

Histria[editar | editar cdigo-fonte]

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, freqentemente 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.

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, 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 um trabalho para a conferncia OOPSLA, eles apresentaram alguns
padres para a construo de janelas na linguagem Smalltalk.[5] Nos anos seguintes Beck,
Cunningham e outros seguiram com o desenvolvimento destas ideias.
O movimento ao redor de padres 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, 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]

Os padres "GoF" so organizados em 3 famlias :

Padres de criao : relacionados criao de objetos

Padres estruturais : tratam das associaes entre classes e objetos.

Padres comportamentais : tratam das interaes e divises de

responsabilidades entre as classes ou objetos.

Padres "GoF" organizados nas suas 3 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[editar | editar cdigo-fonte]

Chain of Responsibility

Command

Interpreter

Iterator

Mediator

Memento

Observer

State

Strategy

Template Method

Visitor

Um padro "GoF" tambm classificado segundo o seu escopo em 2 outros grupos :

Padres com escopo de classe : definido por relacionamentos de herana e

em tempo de compilao.

Padres com escopo de objeto : encontrados no relacionamento entre os objetos

definidos em tempo de execuo.

Padres GRASP[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 utilizados pelo GRASP so: Controlador (Controller), Criador (Creator),
Indireo (Indirection), Especialista na informao (Information expert), Alta coeso (High
Cohesion), Baixo acoplamento (Loose coupling), Polimorfismo (Polymorphism), Variaes
protegidas (Protected variations), e Inveno pura (Pure fabrication).
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.
A principal obra sobre o assunto foi o livro "Utilizando UML e Padres" de autoria de Craig
Larman.[6]

Padres[editar | editar cdigo-fonte]

Especialista na Informao

Criador (ver Factory Method)

Controlador (ver Model-view-controller)

Acoplamento fraco (ver Acoplamento))

Alta coeso (ver Coeso)

Polimorfismo

Indireo

Variaes Protegidas

Crticas[editar | editar cdigo-fonte]

Segundo alguns usurios, alguns 'Padres de Projeto' so apenas evidncias de que
alguns recursos esto ausentes em uma determinada linguagem de programao
(Java ou C++ por exemplo). Nesta linha, Peter Norvig demonstra que 16 dos 23 padres
do livro 'Design Patterns' so simplificados ou eliminados nas linguagens Lisp ou Dylan,
usando os recursos diretos destas linguagens.[7]
Segundo outros, excessos nas tentativas de fazer o cdigo se conformar aos 'Padres de
Projeto' aumentam desnecessariamente a sua complexidade.[8]