Flvio Pernes de Medeiros

METODOLOGIA DA PESQUISA II






Rio de Janeiro
Flvio Pernes de Medeiros








Maro de 2011



ii
Agradecimentos









A minha famlia em especial minha esposa Newli Maura e filhos Bruno e Nicole.


Aos professores em especial ao Oswaldo Borges.


A Deus, pelo dom da vida.






ii
RESUMO

Um padro de projeto uma estrutura recorrente no projeto de software orientado a
objetos. Pelo fato de ser recorrente, vale a pena que seja documentada e estudada.
Um padro de projeto nomeia, abstrai e identifica os aspectos chave de uma estrutura de
projeto comum para torn-la til para a criao de um projeto orientado a objetos
reutilizvel.

Palavras-Chave: Java, Padres, Design, Patterns, Reuso.





iv
ABSTRACT

Design Patterns describe solutions to recurring problems in developing systems of
object-oriented software. A design pattern provides a name and define the problem, the
solution when this solution and its consequences.
The design patterns to facilitate reuse of design solutions - that is, solutions in the
design phase of the software, without considering code reuse. They will also carry a
common vocabulary of design, facilitating communication, learning and documentation
of software systems.






v
Padres de projeto Estrutural
















Monografia apresentada Universidade
Estcio de S, como requisito final do
curso de ps-graduao em
Desenvolvimento de sistemas - JAVA.

Orientador: Prof. JOO MENDES
















Rio de Janeiro
03/2011







vi
Sumrio


1 Introduo 1


1.1 - Tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 - Delimitao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 - Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 - Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 - Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 - Descrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Descobrindo padres no projeto 6


2.1 - Principal alvo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 - Abstraes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 - Como escolher o padro certo. . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Padres de projeto em detalhes 8


3.1 - Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1 Quando usar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2 Classe adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.3 Objeto adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.4 Onde esto os adapters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.5 Duas formas de Adapter. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.6 Objeto Adapter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.7 Implemantao em Java do padro adapter. . . . . . . . . . . . . 8



vi
3.2 - Bridge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1 Motivao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2 Aplicabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3 Vantagens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.4 Implementao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 - Composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.1 Motivao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.2 Aplicabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.3 Vantagens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.4 Implementao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 - Decorator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.1 Motivao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.2 Aplicabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.3 Estrutura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.4 Implementao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.5 Vantagens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5 - Faade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5.1 Motivao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5.2 Aplicabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.3 Estrutura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.4 Participantes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5.5 Vantagens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5.6 Implementao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6 - Flyweight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6.1 Motivao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6.2 Aplicabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6.3 Vantagens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28



vi
3.6.4 Implementao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6.5 Conseqncias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.7 - Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.7.1 Motivao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.7.2 Aplicabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.7.3 Vantagens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.7.4 Conseqncias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.7.5 Implementao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 Concluso 33

Bibliografia 34





ix
Lista de Figuras

3.1 Exemplo da representao do padro de projeto adapter. 9
3.1.5 Exemplo da representao do padro de projeto adapter com herana
mltipla.
10
3.1.6 Exemplo da representao do padro de projeto adapter usando
composio.
10
3.1.7 Exemplo de implementao java do padro de projeto adapter. 11
3.2 Exemplo estrutural do padro de projeto bridge. 12
3.2.1 Exemplo da aplicao do padro de projeto bridge. 14
3.3 Estrutura do padro de projeto composite. 16
3.4 Estrutura do padro decorator. 19
3.4.1 Exemplo de aplicao. 20
3.5 Exemplo de herana. 22
3.5.1 Exemplo de uso com interface. 23
3.5.2 Exemplo de uso de interface com herana. 24
3.5.3 Exemplo de uso facade para casos complexos. 26
3.6 flyweights. 29
3.7 padro proxy. 32

1
Captulo 1
Introduo

1.1 Tema

Com a maturidade na engenharia de softwares, novos aspectos e novas
abordagens foram surgindo at atingirmos o que chamamos de padres de projetos.
Seu uso busca o mapeamento de solues para problemas similares e ou
conhecidos, ao invs de se desenvolver solues a cada novo problema, busca-se
primeiro identificar os problemas e aplicar a soluo conhecida, diminuindo assim,
erros, tempo de construo e praticando reuso.
Neste trabalho abordaremos a aplicabilidade dos padres estruturais.

O conceito de padro de projeto foi criado na dcada de 70 pelo arquiteto
Christopher Alexander.[1] Em seus livros, ele estabelece que um padro deve ter,
idealmente, as seguintes caractersticas:
No presente trabalho iremos detalhar apenas o padro estrutural.
Encapsulamento: um padro encapsula um problema/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

2
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. Em um trabalho para a conferncia OOPSLA, eles apresentaram alguns

3
padres para a construo de janelas na linguagem Smalltalk.[2] Nos anos seguintes
Beck, Cunningham e outros seguiram com o desenvolvimento destas idias.
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 so Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides,
conhecidos como a "Gangue dos Quatro" (Gang of Four) ou simplesmente "GoF".
Posteriormente, vrios 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 padres conhecidos como GRASP
(General Responsibility Assignment Software Patterns).

1.2 Delimitao

Neste trabalho iremos abordar os tipos de problemas e a forma correta de uso e
aplicabilidade dos padres de projeto, embora haja 23 padres de projeto, classificados
em 3 grandes grupos: Criacionais, Estruturais e Comportamentais, o foco do nosso
trabalho ser o padro Estrutural.



4
1.3 Justificativa

evidente que ao seguir padres de desenvolvimento, as equipes acabaro
trazendo aspectos positivos para seus projetos, alm de tornar seus softwares mais fceis
de manter, conseqentemente reduzindo seu tempo e custo de manuteno.

1.4 Objetivos

Existem vrios objetivos e com a aplicabilidade de padres de projeto, Os
softwares s tendem a ganhar, no importa o tamanho do projeto, pode ser um pequeno
projeto ou um grande projeto, seguir padres sempre acabar trazendo vantagens, as
principais que podemos citar so:

Facilidade na manuteno;
Melhoria da documentao;
Melhora a viso geral do sistema;
Melhora a leitura e entendimento do cdigo;
Facilita o desenvolvimento com equipes grandes;
Permite que seus cdigos sejam facilmente entendidos por outros, alm de voc.





5
1.5 Metodologia

Este trabalho foi realizado mediante pesquisas e levantamento de material
bibliogrfico, alm de consultas a informaes constantes na internet, tendo como
enfoque artigos cientficos e aplicaes atuais que tratassem sobre o tema abordado.


1.6 Descrio

Alm deste primeiro captulo introdutrio, no captulo dois definimos e
contextualizamos os padres de projeto dentro do processo de desenvolvimento de
softwares. No captulo trs descrevemos as tcnicas e classificao dos padres, bem
como suas aplicabilidades. No capitulo quatro evidenciamos nossas concluses.



6
Captulo 2
Descobrindo padres no projeto
2.1 Principal alvo
O alvo principal do uso dos padres de projeto no desenvolvimento de software
o da orientao a objetos. Como os objetos so os elementos chaves em projetos OO,
a parte mais difcil do projeto a decomposio de um sistema em objetos. A tarefa
difcil porque muitos fatores entram em jogo: encapsulamento, granularidade,
dependncia, flexibilidade, desempenho, evoluo, reutilizao e assim por diante.
Todos influenciam a decomposio, freqentemente de formas conflitantes. [3]

Muito dos objetos participantes provm do mtodo de anlise. Porm, projetos
orientados a objetos acabam sendo compostos por objetos que no possui uma
contrapartida no mundo real.

2.2 Abstraes
As abstraes que surgem durante um projeto so as chaves para torn-lo
flexvel. Os padres de projeto ajudam a identificar abstraes menos bvias bem como
os objetos que podem captur-las. Por exemplo, objetos que representam processo ou
algoritmo no ocorrem na natureza, no entanto, eles so uma parte crucial de projetos
flexveis. Esses objetos so raramente encontrados durante a anlise ou mesmo durante
os estgios iniciais de um projeto; eles so descobertos mais tarde, durante o processo
de tornar um projeto mais flexvel e reutilizvel.



7
2.3 Como escolher o padro certo
Escolher dentre os padres existentes aquele que melhor soluciona um problema
do projeto, sem cometer o erro de escolher de forma errnea e torn-lo invivel, uma
das tarefas mais difceis. Em suma, a escolha de um padro de projeto a ser utilizado,
pode ser baseada nos seguintes critrios:
Considerar como os padres de projeto solucionam problemas de projeto.
Examinar qual a inteno do padro, ou seja, o que faz de fato o padro de
projeto, quais seus princpios e que tpico ou problema particular de projeto ele trata
(soluciona).
Estudar como os padres se relacionam.
Estudar as semelhanas existentes entre os padres.
Examinar uma causa de reformulao de projeto
Considerar o que deveria ser varivel no seu projeto, ou seja, ao invs de
considerar o que pode forar uma mudana em um projeto, considerar o que voc quer
ser capaz de mudar sem reprojet-lo.




8
Captulo 3
Padres de projeto em detalhes
P Pa ad dr r e es s e es st tr ru ut tu ur ra ai is s

3.1 Adapter

"Objetivo: converter a interface de uma classe em outra interface esperada pelos
clientes. Adapter permite a comunicao entre classes que no poderiam trabalhar juntas
devido incompatibilidade de suas interfaces." [4]

3.1.1 Quando usar

Sempre que for necessrio adaptar uma interface para um cliente.
3.1.2 Classe Adapter

Quando houver uma interface que permita a implementao esttica.
3.1.3 Objeto Adapter

Quando menor acoplamento for desejado.
Quando o cliente no usa uma interface Java ou classe abstrata que possa ser
estendida.
3.1.4 Onde esto os adapters

A API do J2SDK.



9

Figura 3.1 Exemplo da representao do padro de projeto adapter.



10

3.1.5 Duas formas de Adapter

Classe Adapter: usa herana mltipla
Figura 3.1.5 Exemplo da representao do padro de projeto adapter com herana multipla.


Cliente: aplicao que colabora com objetos aderentes interface Alvo
Alvo: define a interface requerida pelo Cliente
Classe Existente: interface que requer adaptao
Adaptador(Adapter): adapta a interface do Recurso interface Alvo


3.1.6 Objeto Adapter: usa composio

Figura 3.1.6 Exemplo da representao do padro de projeto adapter usando composio.





11
nica soluo se Alvo no for uma interface Java
Adaptador possui referncia para objeto que tera sua interface adaptada (instncia de
Classe Existente).
Cada mtodo de Alvo chama o(s) mtodo(s) correspondente(s) na interface adaptada.
3.1.7 Implemantao em Java do padro adapter

Classe Adapter:


Figura 3.1.7 Exemplo de implementao java do padro de projeto adapter.



12
3.2 Bridge

"Desacoplar uma abstrao de sua implementao para que os dois possam variar
independentemente." [4]

3.2.1 Motivao:

O que motiva a utilizao do padro Bridge a necessidade de um driver,
permitindo implementaes especficas para tratar objetos em diferentes
meios persistentes.

3.2.2 Aplicabilidade:

Quando for necessrio evitar uma ligao permanente entre a interface e a
implementao.
Quando alteraes na implementao no puderem afetar clientes.
Quando implementaes so compartilhadas entre objetos desconhecidos do
cliente.

Figura 3.2 Exemplo estrutural do padro de projeto bridge.




13
3.2.3 Vantagens

Detalhes de implementao totalmente inacessveis aos clientes.
Eliminao de dependncias em tempo de compilao das implementaes.
Implementao de abstrao pode ser configurada em tempo de execuo.

3.2.4 Implementao:

A implementao (adaptado [5]) do Padro Bridge ilustra a Ponte entre a
classe abstrata ObetoNegocios a ClienteDadosObjeto atravs de interface
DadosObjeto. A interface DadosObjeto no igual a ObjetoNegocios, j
que no existe necessria dependncia entre elas.
Este exemplo demonstra desacoplamento de uma abstrao de ObjetoNegocio
da implementao em DadosObjeto. As implementaes de DadosObjeto
podem evoluir dinamicamente sem propagar mudanas a nenhum dos
objetos cliente, isso pode ser verificado na figura 3.2.1.
Na classe ClienteDadosObjeto encontra-se a implementao que a classe
cliente espera atravs da DadosObjeto, neste caso, ela contm algumas
pessoas cadastradas, ela pode adicionar novas pessoas em determinado
grupo ou mostr-las. Para interagir entre os cadastros utiliza-se o Padro
Iterator, que ser detalhado nos prximos Padres.



14

Figura 3.2.1 Exemplo da Aplicao do Padro de Projeto Bridge



15

3.3 Composite

Compe objetos em estruturas do tipo rvore para representar hierarquias todo-parte.
Faz tambm com que o tratamento dos objetos individuais e de suas composies seja
uniforme.

3.3.1 Motivao

Aplicaes grficas como editores de desenho e sistemas de captura de
esquema deixam os usurios construrem diagramas complexos a partir de
Componentes simples. O usurio pode agrupar Componentes para formar
Componentes maiores, que, por sua vez, podem ser agrupados para formar
Componentes maiores ainda. O Padro Composite descreve como usar
composio recursiva, de modo que os clientes no tenham que fazer
distino entre componentes simples e composies.
3.3.2 Aplicabilidade

Use o Padro de Projeto Bridge quando:

Quiser representar hierarquias parte-todo de objetos;
Deseja que os clientes sejam capazes de ignorar as diferenas entre
composio de objetos e objetos individuais. Clientes trataro todos os
objetos uniformemente na estrutura Composite.
3.3.3 Vantagens

Objetos complexos podem ser compostos de objetos mais simples
recursivamente.
Facilita a adio de novos componentes.



16
3.3.4 Implementao

Componente:
Declara a interface para objetos na composio;
Implementa comportamento default para interface comum a todas as
classes, como apropriado;
Declara uma interface para acessar ou gerenciar seus Componentes filhos;
Folha:
Representa objetos folhas na composio. Uma folha no tem filhos;
Define comportamento para objetos primitivos na composio.

Composio:
Define comportamento para Componentes que tm filhos;
Armazena Componentes filhos;
Implementa operaes relacionadas com filhos na interface do
Componente.

Cliente:
Manipula objetos na composio atravs da interface Componente

Figura 3.3 Estrutura do Padro de Projeto Composite



17
3.4 Decorator

Agregar responsabilidades adicionais a um objeto dinamicamente. Classes decoradoras
oferecem uma alternativa flexvel ao uso de herana para estender uma funcionalidade
[5].

3.4.1 Motivao
Adicionar responsabilidades a um objeto, mas no sua classe. Acontece, por
exemplo, com criao de interfaces grficas, quando se deseja acrescentar
uma borda a um componente qualquer ou uma barra de rolagem a uma rea
de texto. Uma abordagem mais flexvel inserir o componente em outro
objeto que adiciona a borda, um Decorator [5].

3.4.2 Aplicabilidade

Utilizado para adicionar responsabilidades a objetos individuais de forma
dinmica e transparente, isto , sem afetar outros objetos, da mesma forma,
quando se quer retirar responsabilidades.

Quando a utilizao de heranas para a implementao do mesmo afetar a
flexibilidade do sistema [6].

Um caso de aplicao do Decorator quando existem muitas variaes de um
objeto. Imagine por exemplo uma classe Janela com uma subclasse
JanelaComBorda. Se houver a necessidade tambm de janelas com
rolagem, tem-se ainda JanelaComRolagem e JanelaComBordaERolagem
[6], alm de outras possveis combinaes, j que poderia haver menus,
botes ou barra de status.




18
Usando o Decorator, tem-se um nmero muito menor de subclasses: Janela,
DecoratorJanela, DecoratorJanelaBorda, DecoratorJanelaRolagem,
DecoratorJanelaMenu, e assim por diante [6].

3.4.3 Estrutura

Esse padro providencia que cada objeto Decorator contenha outro objeto
Decorator. Nesse aspecto, um decorator como um pequeno composite
cujos elementos possuem cada qual um filho nico. Diferentemente do
padro Composite, cujo propsito compor objetos agregados, o propsito
do Decorator compor comportamentos.

3.4.4 Implementao

Componente : define a interface para objetos que podem ter responsabilidades
acrescentadas a eles dinamicamente.

ComponenteConcreto : define um objeto para o qual responsabilidades
adicionais podem ser atribudas

Decorator : mantm uma referncia para um objeto Componente. Define uma
interface que segue a interface de Componente.

DecoratorConcretoA e DecoratorConcretoB: acrescenta responsabilidades ao
componente




19


Figura 3.4 Estrutura do padro Decorator


3.4.5 Vantagens:

Fornece uma flexibilidade maior do que a herana esttica.
Evita a necessidade de colocar classes sobrecarregadas de recursos em uma
posio mais alta da hierarquia.
Simplifica a codificao permitindo que voc desenvolva uma srie de
classes com funcionalidades especficas, em vez de codificar todo o
comportamento no objeto.
Aprimora a extensibilidade do objeto, pois as alteraes so feitas
codificando novas classes.



20
3.4.5 Implementao


Figura 3.4.1 exemplo de aplicao

O exemplo ilustrado na Figura 3.4.1, visa gerar janelas com caractersticas
que podem variar de uma janela para outra. Por exemplo, o cliente pode
decidir entre construir uma janela com barra de menus ou no. Desta forma
consegue-se aumentar o nmero de possibilidades de janelas diferentes
apresentadas com um pequeno nmero de classes.
Neste exemplo, a interface Janela recebe o papel de ser o Componente da
estrutura apresentada anteriormente. Por sua vez, JanelaComum interpreta
o ComponenteConcreto, ou seja, ele que receber as modificaes no
decorrer da execuo da aplicao. Como o prprio nome diz, o Decorator
assume a finalidade do Decorator da estrutura padro. JanelaMenuBar,
JanelaBorda, JanelaBarraStatus e JanelaBarraFerramenta herdam de
Decorator, ou seja, so os n decoradores concretos.



21


3.5 Faade

Oferecer uma interface nica para um conjunto de interfaces de um subsistema.
Definir uma interface de nvel mais elevado que torna o subsistema mais fcil de usar
[5].
Reduzir a complexidade do relacionamento entre uma classe relativa ao cliente e as
demais classes utilitrias [5].

3.5.1 Motivao:

Uma grande vantagem da programao orientada a objetos que ela ajuda a
evitar que as aplicaes se tornem programas monolticos, com pedaos
incorrigivelmente entrelaados. No entanto, a aplicabilidade variada das
classes em um subsistema orientado a objetos pode oferecer uma variedade
expressiva de opes [7].
Existem circunstncias onde necessrio utilizar diversas classes diferentes
para que uma tarefa possa ser completada, caracterizando uma situao
onde uma classe cliente necessita utilizar objetos de um conjunto especfico
de classes utilitrias que, em conjunto, compem um subsistema particular
ou que representam o acesso a diversos subsistemas distintos [7], como
ilustrado na Figura abaixo.



22

Figura 3.5 exemplo de herana



3.5.2 Aplicabilidade

Criao de interfaces mais simples para um ou mais subsistemas complexos.
Reduo de dependncia entre o cliente e as classes existentes nos
subsistemas, ocasionando a reduo da coeso do sistema
Criao de sistemas em camadas. Este padro prov o ponto de entrada para
cada camada (nvel) do subsistema.

3.5.3 Estrutura

A estrutura deste padro, apresentado nas figuras Facade 3.5.1 e Facade 3.5.2,
bastante simples. A classe que constituir o Facade dever oferecer um
conjunto de operaes que sejam suficientes para que seus clientes possam
utilizar adequadamente o subsistema, embora sem conhecer as interfaces de
seus componentes [6].
O Facade um padro que pode apresentar infinidades de formas de
represent-lo. O que importa para este padro que o Cliente apenas acesse
objetos da classe Facade, esperando algum resultado vindo dela. A classe
Facade que ter a responsabilidade de entrar em contato com as diversas
instncias dentro deste sistema, efetuar possveis clculos vindos de classes
abaixo dela e retornar as respostas que o cliente pediu.



23

Figura facede 3.5.1 exemplo de uso com interface




24

Figura facade 3.5.2 exemplo de uso de interface com herana


3.5.4 Participantes
Cliente : aguarda respostas da interao do Facade e as Classes do
subsistema.
Facade : conhece quais classes do subsistema seriam responsveis pelo
atendimento de uma solicitao e delega solicitaes de clientes a objetos
apropriados dos subsistemas.
Classes de subsistema : (ClasseA, ..., ClasseB)
Implementam as funcionalidades do subsistema.
Respondem a solicitaes de servios da Facade.



25
No tm conhecimento da Facade.

3.5.5 Vantagens:

Protege os clientes da complexidade dos componentes do subsistema;
Promove acoplamento fraco entre o subsistema e seus clientes;
Reduz dependncias de compilao, possivelmente complexas ou circulares;
Facilita a portabilidade do sistema [5];
Reduz a unio entre subsistemas desde que cada subsistema utilize seu
prprio padro Facade e outras partes do sistema utilizem o padro Facade
para comunicar-se com o subsistema [5];
No evita que aplicaes possam acessar diretamente as subclasses do
sistema, se assim o desejarem [5];

3.5.6 Implementao:

Implementar um Facade demanda definir um conjunto de operaes reduzidas
que permita ocultar a complexidade inerente utilizao de vrias classes
de um subsistema (adaptado [5]).




26

Figura 3.5.3 exemplo de uso facade para casos complexos.

Neste exemplo, ilustrado na Figura 3.5.3, o cliente necessita consultar vrias
entidades a fim de saber se tm condies de receber um emprstimo. Para
isso, normalmente, o cliente teria que conhecer toda a complexidade
envolvida com as regras de concesso de emprstimos e aprende-las, no
entanto, nada melhor do que deixar isso a cargo de quem j est no sistema,
no caso o Facade, que ir se preocupar em colher dados das diferentes
classes que podem decidir sobre a possibilidade do emprstimo e retornar
esta informao pronta para o cliente.
FacadeApp o cliente que busca informaes que podem vir de vrios de
subsistemas, Facade a classe responsvel por acessar os subsistemas e
trazer respostas de forma transparente a quem esteja acessando o Facade.
Banco, Emprestimo, Crdito e Consumidor so classes pertencentes aos
subsistemas.





27


3.6 Flyweight


3.6.1 Motivao:

O padro de projeto Flyweight um padro estrutural que tem por finalidade
usar de compartilhamento de objetos de granularidade fina, isto , objetos
que so iguais exceto pequenos detalhes.
Este padro procura fatorar as informaes comuns a diversos objetos em um
nico componente. Os demais dados, que tornam tais objetos nicos,
passam a ser utilizados como parmetros de mtodos [7].

Utilizando desse padro possvel reduzir consideravelmente o nmero de
objetos em uma aplicao devido ao fato de que objetos com as mesmas
caractersticas so unificados em apenas um. Porm importante ressaltar
que esse padro indicado quando se tem uma aplicao com um nmero
considervel de objetos que podem ser compartilhados, alm de essa
aplicao no depender da quantidade de objetos.

Existem dois estados dos objetos que devem ser levados em conta na adoo
do padro flyweight, os estados intrnseco e extrnseco. O primeiro diz
respeito parte do objeto que ser imutvel independente do cliente, estar
armazenado no objeto Flyweight e o estado que ser compartilhado. O
segundo est relacionado parte do objeto que ser mutvel e estar
armazenado no cliente.



28
3.6.2 Aplicabilidade:

A aplicao usa uma grande quantidade de objetos.
Custos de armazenamento so altos, por causa da imensa quantidade de
objetos.
Parte considervel do estado do objeto pode ser tornar extrnseco uma vez que
o estado extrnseco removido, muitos agrupamentos de objetos podem ser
substitudos por uma quantidade consideravelmente menor de objetos
compartilhados.
A aplicao no depende de identidade de objetos. Visto que flyweights
podem ser compartilhados, testes de identidade iro retornar true para
objetos conceitualmente distintos.

3.6.3 Vantagens:

A principal conseqncia do uso do padro Flyweight a economia de
memria devido reduo do nmero de instncias e quantidades de estado
intrnseco. [8] Podem ser introduzidos custos em termos de eficincia
devido transferncia, procura e/ou computao do estado extrnseco [...],
devido a isso antes de se adotar esse padro de projeto importante avaliar
se a quantidade de memria economizada compensa realmente a possvel
perda de eficincia.



29

3.6 flyweights.

3.6.3 Implementao:


Participantes :
Flyweight :Declara uma interface atravs da qual os objetos flyweight podem
receber seu estado extrnseco.
ConcreteFlyweight (Caracter) : Implementa a interface Flyweight e adiciona
os atributos para guarder o estado extrnseco, se houver algum. Um objeto
ConcreteFlyweight precisa ser compartilhavel. Qualquer estado que ele
guarde precisa ser intrnseco, ou seja, precisa ser idependente do contexto
do objeto ConcreteFlyweight.
UnsharedConcreteFlyweight (Linha, Coluna) : Nem todas as subclasses de
Flyweight precisam ser compartilhadas. A interface Flyweight permite o
compartilhamento, mas no obriga. comum para a classe
UnsharedConcreteFlyweight ter a classe ConcreteFlyweight como filha em
algum nvel da estrutura de classes do flyweight.



30
FlyweightFactory :Cria e gerencia objetos flyweight. Garante que os
flyweights sero compartilhados adequadamente. Quando um flyweight
requerido, o objeto FlyweightFactory fornece uma instncia existente ao
invs de criar uma nova, se nenuma existir.
Client : Mantm referncia para o(s) flyweight(s). Calcula ou guarda o estado
extrnseco do(s) flyweight(s).

3.6.4 Conseqncias:

Flyweights podem introduzir custos em tempo de execuo associados com
transferir, buscar e ou computar o estado extrnseco. Apeasr disso, os custos
so compensados pela economia de espao, que cresce conforme mais
objetos flyweights so compartilhados. A economia de espao funo de
vrios fatores: a reduo do nmero total de instncias que vm com o
compartilhamento a quantidade de estados intrnsecos por objeto




31
3.7 Proxy

3.7.1 Motivao:

O padro Proxy prov uma referncia para um objeto com o objetivo de
controlar o acesso a este.[5]

O padro Proxy utilizado quando um sistema quer utilizar um objeto real,
mas por algum motivo ele no est disponvel. A soluo ento
providenciar um substituto que possa se comunicar com esse objeto quando
ele estiver disponvel. O cliente passa a usar o intermedirio em vez do
objeto real. O intermedirio possui uma referencia para o objeto real e
repassa as informaes do cliente, filtrando dados e acrescentando
informaes.
3.7.2 Aplicabilidade:

Remote Proxy - prov um representate local para um objeto em um espao de
endereamento diferente.
Virtual Proxy - cria objeto sob demanda.
Protection Proxy - controla acesso ao objeto original.
Smart References - executa operaes adicionais quando o objeto acessado
Contagem de referncias, carga de objetos persistentes, locks.
Copy-on-write - compartilhar grandes objetos, fazendo uma cpia apenas se
necessrio.
[9] enumera vantagens e desvantagens de padro.




32
3.7.3 Vantagens:

Transparncia, pois utilizada a mesma sintaxe na comunicao entre o
cliente e o objeto real;
Tratamento inteligente dos dados no cliente e
Maior eficincia com caching no cliente.

3.7.4 Conseqncias:

Possvel impacto na performance e Fatores externos como queda da rede pode
deixar o Proxy inoperante.
3.7.5 Implementao:



3.7 padro proxy



33
Captulo 6
Concluso

Atualmente as metodologias geis, os padres de projetos e orientao a objetos
so temas amplamente discutidos e de muita relevncia no contexto da tecnologia da
informao.
Nunca antes na histria da informtica se usou e ousou tanto da informtica
quanto nesta era da web 2.0, empresas particulares, esferas de governo,
interoperabilidade de sistemas, tudo isso tem preo e conseqncias, podendo ser o
sucesso ou fracasso.
neste ambiente heterogneo e nem sempre com fronteiras claras que os
padres de projeto fazem diferena, o seu uso correto e a identificao precoce trazem
claras vantagens e diversas melhorias, tanto para o desenvolvimento quanto para a
equipe de gesto, uma vez que promove a neguentropia, pois sabemos que sem isto todo
sistema tende a morte e quanto mais fcil ela for a manutenibilidade, mais vida til ter
o sistema.
Neste contexto de expanso da tecnologia da informao e dos servios a que se
prope, fica claro que a maturidade dos arquitetos de sistema imperativa, posto que
so eles que definem os padres de projeto.
Esta fase deve preceder todo o desenvolvimento de sistemas, o correto mapeamento dos
padres de projeto, so a causa de boa parte no s do sucesso dos projetos mas tambm
de garantias adicionais como manutenes evolutivas de baixo custo, performance e
escalabilidade das aplicaes.



34
Bibliografia
[1] WIKIPEDIA, Padro de projeto de software. Disponvel em
http://pt.wikipedia.org/wiki/Padr%C3%A3o_de_projeto_de_software#cite_note-0 ,
acessado em 10/11/2010.
[2] WIKIPEDIA, Padro de projeto de software. Disponvel em
http://pt.wikipedia.org/wiki/Padr%C3%A3o_de_projeto_de_software#cite_note-2 ,
acessado em 11/02/2011.
[3] GAMMA, Erich, HELM, Richard; JOHNSON, Ralph, VLISSIDES, John. Padres
de Projeto: solues reutilizveis de software orientado a objetos. 1. ed. Porto Alegre:
Bookman, 2000.

[4] Taylor, Lenore. "The Rudd gang of four", The Australian, Sydney, 09 November
2009. Retrieved on 2010-06-18.

[5] Markus Schumacher, Eduardo Fernandez-Buglioni, Duane Hybertson, Frank
Buschmann, Peter Sommerlad. Security Patterns: Integrating Security and Systems
Engineering, Wiley Series in Software Design Patterns, 2005.

[6] CEFETPR, Padres de projeto. Disponvel em
http://www.pg.cefetpr.br/coinf/simone/patterns/decorator.php,
acessado em 11/02/2011.

[7] METSKER, S. J. Padres de Projeto em Java. Porto Alegre. Bookman, 2004

[8] Design Patterns Java Workbook, Metsker S., Addison-Wesley, 2002

[9] GFSOLUES, Padro de projeto. Disponvel em
http://www.gfsolucoes.net/trabalhos/padroes_de_projetos.pdf ,
acessado em 10/03/2011.




35
B. Apndice B
Encadernao do Projeto Final