Luis Francisco Thomazini Neto 0300743, 8 Semestre

Padres de Projetos

Jaguarina 2006

Luis Francisco Thomazini Neto

0300743, 8 Semestre

Padres de Projetos

Relatrio parcial apresentado disciplina Trabalho de Graduao III, do curso de Cincia da Computao da Faculdade de Jaguarina, sob orientao do Prof. Ms. Peter Jandl Jr., como exigncia parcial para concluso do curso de graduao.

Jaguarina 2006

SUMRIO
1. INTRODUAO ...........................................................................................................9 2. PADRES DE PROJETO .......................................................................................10 2.1. Origem .................................................................................................................10 2.2. O que so?.............................................................................................................11 2.3. Definies ............................................................................................................12 2.4. Por que usar?.........................................................................................................13 2.5. Quando usar? ........................................................................................................13 2.6. Detectando um bom Design Pattern ....................................................................13 2.7. Qualidades dos padres de Projetos .....................................................................14 2.8. Design Patterns versus Frameworks.......... ..........................................................15 3. PADRES GOF .........................................................................................................15 3.1. Tipos de padres GOF ..........................................................................................16 3.2. Relaes entre Padres .........................................................................................17 3.3. Componentes de um Padro de Projetos ..............................................................17 3.4. Outra definio para padro de projetos ..............................................................18 3.5. A linguagem de padro ........................................................................................19 3.6. Seleo de Padres de Projeto .............................................................................19 4. ANALISE DOS PADRES DE PROJETO SELECIONADOS ..........................20 4.1. Singleton ..............................................................................................................20 4.1.1. Motivao .........................................................................................................20 4.1.2. Conseqncias ..................................................................................................21 4.1.3. Exemplo ..........................................................................................................21 4.1.4. Aplicabilidade ...................................................................................................22 4.1.5. Estrutura ............................................................................................................22 4.1.6. Cdigo Exemplo ................................................................................................23 4.2. Iterator ..................................................................................................................24 4.2.1 .Motivao .........................................................................................................24 3

4.2.2. Aplicabilidade ....................................................................................................24 4.2.3. Estrutura .............................................................................................................24 4.2.4. Aplicabilidade ....................................................................................................24 4.2.5. Estrutura .............................................................................................................25 4.2.6. Cdigo exemplo .................................................................................................26 4.3. Faade.....................................................................................................................27 4.3.1. Motivao............................................................................................................27 4.3.2. Conseqncias.....................................................................................................27 4.3.3. Exemplo..............................................................................................................27 4.3.4. Aplicabilidade.....................................................................................................27 4.3.5. Estrutura..............................................................................................................28 4.3.6. Cdigo exemplo..................................................................................................28 4.4. Factory method......................................................................................................29 4.4.1 Motivao............................................................................................................29 4.4.2 Conseqncias.....................................................................................................30 4.4.3 Exemplo...............................................................................................................30 4.4.4. Aplicabilidade.....................................................................................................30 4.4.5. Estrutura..............................................................................................................31 4.4.6. Cdigo exemplo..................................................................................................31 4.5. Abstract Factory ...................................................................................................32 4.4.1 Motivao............................................................................................................32 4.5.2 Conseqncias.....................................................................................................32 4.5.3 Exemplo..............................................................................................................33 4.5.4. Aplicabilidade....................................................................................................33 4.5.5. Estrutura.............................................................................................................33 4.5.6. Cdigo exemplo.................................................................................................34 4.6. Observer................................................................................................................36 4.6.1 Motivao............................................................................................................36 4.6.2 Conseqncias.....................................................................................................36 4.6.3 Exemplo..............................................................................................................36 4.6.4. Aplicabilidade....................................................................................................37 4.6.5. Estrutura.............................................................................................................37 4.6.6. Cdigo exemplo.................................................................................................37 4.7. Adapter.................................................................................................................39 4

4.7.1 Motivao...........................................................................................................39 4.7.2 Conseqncias....................................................................................................39 4.7.3 Exemplo..............................................................................................................39 4.7.4. Aplicabilidade....................................................................................................40 4.7.5. Estrutura.............................................................................................................40 4.7.6. Cdigo exemplo.................................................................................................40 4.8. Bridge....................................................................................................................41 4.8.1 Motivao............................................................................................................41 4.8.2 Conseqncias.....................................................................................................41 4.8.3 Exemplo..............................................................................................................41 4.8.4. Aplicabilidade....................................................................................................42 4.8.5. Estrutura.............................................................................................................43 4.8.6. Cdigo exemplo.................................................................................................43 4.9. Decorator...............................................................................................................43 4.9.1 Motivao............................................................................................................43 4.9.2 Conseqncias.....................................................................................................44 4.9.3 Exemplo..............................................................................................................44 4.9.4. Aplicabilidade....................................................................................................44 4.9.5. Estrutura.............................................................................................................44 4.9.6. Cdigo exemplo.................................................................................................45 4.10. Memento.............................................................................................................45 4.10.1 Motivao.........................................................................................................46 4.10.2 Conseqncias..................................................................................................46 4.10.3 Exemplo...........................................................................................................46 4.10.4. Aplicabilidade.................................................................................................47 4.10.5. Estrutura..........................................................................................................47 4.10.6. Cdigo exemplo..............................................................................................47 5. 6. 7. RESULTADOS ESPERADOS................................................................................48 REFERENCIAS BIBLIOGRAFICAS...................................................................49 ASSINATURAS.......................................................................................................50

THOMAZINI, Luis Francisco. Padres de projetos. 2006. Monografia (Bacharelado em Cincia da Computao) Curso de Cincia da Computao da Faculdade de Jaguarina, Jaguarina.

RESUMO
Neste trabalho ser apresentado alguns dos mais conhecidos padres de projetos de GOF, tambm conhecido pelo termo original em ingls Design patterns. Os padres descrevem solues para problemas recorrentes no desenvolvimento de sistemas de softwares orientados a objetos. Um padro de projeto estabelece um nome e define o problema, a soluo , quando aplicar esta soluo e suas conseqncias. Eles visam facilitar a reutilizao da soluo de desenho. Ou seja, solues na fase de projeto do software, sem considerar reutilizao de cdigo. Sendo asssim os padres de projetos colocam ordens no caos e ajudam a deixar a implementao estruturada e organizada.

Palavras chave: Utilidade, reutilizao e solues.

AO MEU PAI FRANCISCO E MINHA ME FATIMA QUE SEMPRE ME APOIARAM, MOTIVARAM E ME DERAM TODO O SUPORTE PARA CONCLUSO DOS MEUS ESTUDOS. E TAMBM MEU QUERIDO AV WILSON THOMAZINI A QUEM PRESTO MINHAS HOMENAGENS. 7

Agradecimento

Primeiramente agradeo a Deus por ter me abenoado em mais esta caminhada por ter me dado sade e perseverana nas horas difceis. agradeo tambm a todos os professores e amigos da FAJ, pela orientao e apoio quando solicitado e durante toda essa nossa caminhada pois juntos vivemos altos e baixos mas sempre com os mesmos objetivos. E em particular: ao Prof. Leonardo Hartleben Heinehr por ter dado as orientaes iniciais, e principalmente ao Prof. Peter Jandl Jr. pela orientao dedicada e pelo apoio ministrado no decorrer deste trabalho.

1. INTRODUO
Desenvolver software no tarefa das mais fceis. Um dos fatores que gera esta dificuldade que muitas vezes o entendimento do problema no est muito claro. Alm disso, h uma escassez grande na documentao dos problemas e nas solues encontradas para solucion-los. Com isso, problemas que muitas vezes se repetem, geram esforos adicionais para a implementao de suas solues. As tentativas de reuso das boas solues e do acmulo de experincias sobre determinados problemas so, na maioria das vezes, iniciativas isoladas de alguns desenvolvedores. O uso do design patterns vem preencher esta lacuna que existe, tornando-se um mecanismo eficiente no compartilhamento de conhecimento entre os desenvolvedores (principalmente hoje com o uso da Internet). A meta a criao de uma linguagem comum, que permita uma comunicao efetiva no que se refere troca de experincias sobre problemas e suas solues. Desta forma, solues que se aplicaram as situaes particulares, podem ser novamente aplicadas em situaes semelhantes por outros desenvolvedores. Codificando estas solues, estamos tambm capturando o conhecimento do sistema, indo ao encontro das necessidades dos usurios. A criao de um repositrio de design patterns ajuda tanto ao desenvolvedor experiente quanto ao novato, no reconhecimento de situaes nas qual o reuso poderia ocorrer. O foco principal no nem tanto tecnolgico, mas sim o de criar uma cultura de catalogao de experincias e solues para apoiar o desenvolvimento de software. (JUNQUEIRA, 2002) As idias que deram origem aos padres de projetos ocorreram em um contexto muito diferente da rea de engenharia de software. Em 1977, o arquiteto Christopher Alexander e seus colegas publicaram o livro A pattern language, uma espcie de catalogo com 253 padres construtivos, defendendo que os mtodos tradicionais empregados pela arquitetura no supriam as reais necessidades dos usurios das construes propostas e, portanto, que a arquitetura no atendia a sociedade como deveria, pois seu maior objetivo melhorar a qualidade de vida das pessoas. Cada um dos padres apresentados era como um pequeno manual sobre a questo arquitetnica (JANDL, 2003). Os padres de projeto de software (design patterns) descrevem solues para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. suas conseqncias (WIKIPEDIA, 2006). 9 Um padro de projeto estabelece um nome e define o problema, a soluo, quando aplicar esta soluo e

Os padres de projeto visam facilitar a reutilizao de solues de desenho - isto , solues na fase de projeto do software, sem considerar reutilizao de cdigo. Tambm acarretam um vocabulrio comum de desenho, facilitando comunicao, documentao e aprendizado dos sistemas de software. Devido complexidade dos softwares desenvolvidos atualmente, os padres de projetos chegam para facilitar a concepo de sistemas. Padres de projeto so aplicados em tudo e em todos os lugares, nas cidades, construes, organizaes, e na criao de projetos de softwares tambm. Os padres de projetos facilitam a comunicao entre os desenvolvedores, facilitam a reutilizao de projetos bem sucedidos, proporcionam uma maior tranqilidade quando for necessria a modificao de um projeto e tem documentado toda suas caractersticas, aplicabilidades, solues. Os padres de projeto solucionam muitos dos problemas que os projetistas enfrentam no dia-a-dia, e de muitas maneiras diferentes (GAMMA, 2005). Christopher Alexander afirma: cada padro descreve um problema no nosso ambiente e o cerne da sua soluo, de tal forma que voc possa usar essa soluo mais de um milho de vezes, sem nunca faze-lo da mesma maneira. Sendo assim estudar e analisar esses padres pode se tornar um trabalho muito interessante por que os conhecimentos so ampliados. Podendo assim implementar alguns exemplos de cdigos utilizando padres de projetos e os que no utilizar para em fim poder fazer uma comparao entre os dois tipos de implementao. Este trabalho tem com objetivo principal estudar a origem dos padres de projetos, suas definies, mostrar como eles solucionam os problemas de um projeto, estudar os princpios de aplicaes, apontar as vantagens da utilizao, estudar alguns dos principais padres.

10

2. PADROES DE PROJETO 2.1 Origem

O Design Patterns originam-se no final dos anos 80 quando Ward Cunningham e Kent Beck desenvolveram um conjunto de padres para serem aplicados no desenvolvimento de interfaces do usurio elegantes em Smalltalk. Nesse perodo Jim Coplien estava desenvolvendo um catlogo de padres C++ chamados idiomas. Durante esse perodo, Erich Gamma trabalhava em sua tese de doutorado sobre desenvolvimento de software orientado a objeto, e reconheceu a importncia de acumular explicitamente as estruturas de projetos que se repetiam com freqncia. Essas e outras pessoas intensificaram suas discusses em uma srie de workshops do OOPSLA organizado em 1991 por Bruce Anderson, e em 1993 a primeira verso de um catlogo de padres estava esboada. Essas atividades foram influenciadas pelos trabalhos de Christopher Alexander, um arquiteto urbano que associou o termo "pattern" s repeties de formas em arquitetura. Ele argumentava que os mtodos de arquiteturas no atendiam s reais necessidades dos indivduos e da sociedade. Ele queria criar estruturas que melhorassem a qualidade de vida das pessoas. Era qualidade serio o principal objetivo a ser atingido com o uso dos padres. Design Patterns tambm tem sido usado nos mais diferentes domnios, abrangendo o desde o desenvolvimento de software at o uso em Arquitetura e Educao. Em 1977, Christopher Alexander e seus colegas publicaram o livro A pattern language, uma espcie de catalogo com 253 padres construtivos, defendendo que os mtodos tradicionais empregados pela arquitetura no supriam as reais necessidades dos usurios das construes propostas e, portanto, que a arquitetura no atendia a sociedade como deveria, pois seu maior objetivo melhorar a qualidade de vida das pessoas. Cada um dos padres apresentados era como um pequeno manual sobre a questo arquitetnica (JANDL, 2003).

2.2. O que so?

Poderamos dizer, de forma sucinta, que um um determinado contexto", onde: 11 " uma soluo para um problema em

Contexto se refere ao conjunto de situaes que se repetem, nas quais o design pattern pode ser aplicado; Problema se refere ao conjunto de "foras" objetivos e limitaes que ocorrem dentro do contexto; Soluo uma estrutura formal para ser aplicada na resoluo do problema. A soluo tenta capturar a essncia do problema, a fim de que outros desenvolvedores a entendam, e possam fazer uso dela em situaes similares. Esta definio pode ser escrita de uma outra maneira: " uma relao ternria entre um determinado contexto, um determinado conjunto de foras (objetivos e restries) que ocorrem repetidamente neste contexto, e uma determinada configurao de software que permite que estas foras sejam resolvidas." Em termos de orientao a objetos, design patterns identifica classes, instncias, seus papis, colaboraes e a distribuio de responsabilidades. Seriam, ento, descries de classes e objetos que se comunicam, que so implementados a fim de solucionar um problema comum em um contexto especfico. O design pattern faz mais do que identificar a soluo, ele explica porque a soluo necessria.

2.3. Definies
Os padres de projeto representam um avano importante na rea de orientao a objetos, pois oferecem um catlogo de planos de projeto que permitem a reutilizao de solues de projeto que provaram ser efetivas para resolver problemas semelhantes. Eles do um nome e uma descrio abstrata para estas estruturas, permitindo assim comunicar um projeto em termos de uma linguagem de mais alto nvel que as notaes bsicas. A sua descrio num nvel abstrato permite sua reutilizao para projetar novas aplicaes ou melhorar aplicaes existentes, de forma independente da implementao. Os padres de projeto variam em nvel de abstrao, mas mesmo assim, possuem caractersticas comuns e em alguns casos esto fortemente relacionados. Os padres so classificados de acordo a um sistema que agrupa os diferentes padres em categorias que facilitam sua compreenso e utilizao.

12

2.4. Por que usar?

Design patterns tem vrios usos no processo de desenvolvimento de software orientado a objetos: Formam um vocabulrio comum que permitem uma melhor comunicao entre os desenvolvedores, uma documentao mais completa e uma melhor explorao das alternativas de projeto. Reduz a complexidade do sistema atravs da definio de abstraes que esto acima das classes e instncias. Um bom conjunto de padres aumenta muito a qualidade do programa; Constituem uma base de experincias reutilizveis para a construo de software. Funcionam como peas na construo de projetos de software mais complexos; podem ser considerados como micro-arquiteturas que contribuem para arquitetura geral do sistema; Reduzem o tempo de aprendizado de uma determinada biblioteca de classes. Isto fundamental para o aprendizado dos desenvolvedores novatos; Quanto mais cedo so usados, menor ser o retrabalho em etapas mais avanadas do projeto. (JUNQUEIRA, 2002).

2.5. Quando usar?

Em solues que se repetem com variaes. No faz sentido o reuso, se o problema s aparece em um determinado contexto. Em geral, o design patterns representa solues que requerem vrios passos. Se o nmero de passos for pequeno, no h a necessidade do uso desses. Design patterns se aplica muito bem em situaes em que o desenvolvedor est mais interessado na existncia de uma soluo do que na sua total implementao. Isto ocorre, na maior parte das vezes, quando o domnio do problema o foco da questo.

2.6. Detectando um bom Design Pattern

No so em todos os algoritmo ou prtica que se constitui um padro. Embora possa parecer que possua todos os requisitos bsicos para ser um padro, ele no pode ser considerado como tal at que o fenmeno da repetio seja. Um bom design pattern tem as seguintes caractersticas: 13

Resolve o problema, e no apenas indica princpios e estratgias; um conceito provado, no constituindo apenas uma hiptese ou uma especulao; A soluo no bvia; No apenas descreve os mdulos, mas como eles se relacionam, atravs de estruturas e mecanismos do sistema. Tem um significante componente humano: atinge a qualidade quer seja na clareza, na utilidade, na documentao.

2.7. Qualidades dos Padres de Projeto

Os Design Patterns podem ser vistos como extenso da definio de classes. Em orientao a objetos, as classes tm dois aspectos bsicos, anlogos ao design patterns: Externo, a viso do problema: descries das propriedades, responsabilidades, capacidades e servios prestados ao software ou ao ambiente externo; Interno, a viso da soluo: descries estticas e dinmicas, limitaes, e relacionamentos entre os componentes, colaboradores, ajudantes, cada um apenas com uma viso externa incompleta. Os Design Patterns aumentam a expressividade e o nvel de descrio suportada pela orientao a objetos. Inversamente, os conceitos de OO podem ser aplicados ao design patterns: Encapsulamento e Abstrao. Cada design pattern engloba um problema em um determinado contexto e a sua soluo, com limites bem definidos entre o espao do problema e da soluo. Tambm corresponde a uma abstrao que abrange conhecimento e experincias sobre o domnio da aplicao. Extensibilidade e Adaptabilidade Cada design pattern deve ser extensvel para que outros design patterns possam moldlo a fim de resolver um problema mais amplo. Deve ser tambm adaptvel para que sua soluo possa servir em uma vasta gama de implementaes. Gerao e Composio Cada padro, uma vez aplicado, gera como conseqncia um contexto inicial de um ou mais design patterns. Estes podero ser aplicados em conjunto, com o objetivo de alcanar uma soluo global e completa. Equilbrio 14

Os padres devem procurar atingir um equilbrio entre suas foras e restries. Devemse minimizar os conflitos dentro do espao de soluo do problema, e dar um por que para cada passo ou regra dentro do design pattern.

2.8. Design Patterns versus Frameworks

Um conceito estreitamente relacionado com o de orientao a objetos e o de design patterns o de framework. Um framework consiste em uma arquitetura concreta reutilizvel que prov estruturas genricas para uma famlia de softwares. Um framework pode ser adaptado para atender vrias necessidades dentro de um determinado domnio. Ele no constitui uma aplicao completa, visto que no tem toda a funcionalidade especfica da aplicao. Esta pode ser construda, adicionando funcionalidades a um ou mais frameworks, atravs do mecanismo de heranas e de instanciaes dos seus componentes. (JUNQUEIRA, 2002).

3. PADRES GOF
Os padres "GoF" so organizados em famlias de padres: de criao, estruturais e comportamentais. Os padres de criao so relacionados criao de objetos, os estruturais tratam das associaes entre classes e objetos e os comportamentais das interaes e divises de responsabilidades entre as classes ou objetos. Um padro "GoF" tambm classificado segundo o seu escopo; de classe ou de objeto. Nos padres com escopo de classe os relacionamentos que definem este padro so definidos atravs de herana e em tempo de compilao. Nos padres com escopo de objeto o padro encontrado no relacionamento entre os objetos definidos em tempo de execuo (WIKIPDIA, 2006). Escopo o domnio sobre o qual o padro pode ser aplicado. Os padres categorizados dentro da influncia de classes tratam acerca de relacionamentos entre classes e as suas subclasses. Caracterizao identifica a funo do padro. Os padres Criacionais envolvem o processo de criao de objetos, os Estruturais tratam acerca da forma em que classes e objetos so compostos para formar estruturas de nvel superior. Os padres Comportamentais, por sua

15

vez, caracterizam a forma em que classes e objetos interagem e distribuem responsabilidades (MACKENZIE, 2006).

3.1. tipos de padres GOF

Padres de criao
Abstract Builder Factory Method Prototype Singleton

Factory

Padres estruturais
Adapter Bridge Composite Decorator Faade Flyweight Proxy

Padres comportamentais
Chain

of Responsability

Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor

16

3.2. Relao entre os Padres

Figura 1. Ligaes entre os Padres.

3. 3. Componentes de um padro de Projeto

Existem diversas formas de escrevermos um design pattern. No entanto, independente do formato, os alguns componentes devem ser facilmente reconhecidos quando da leitura de um design pattern. A forma aqui descrita conhecida como forma cannica. Nome e Classificao - Deve expressar a essncia do padro. Um bom nome vital, pois vai se tornar parte do vocabulrio do projeto. Propsito - O que faz o design pattern? Qual o problema que se prope a atacar? Quais os objetivos que deseja alcanar? Motivao - Descreve o cenrio no qual se aplica, todas as foras que esto presentes, as classes e os objetos relacionados. Aplicabilidade - Quais so as situaes na qual o design pattern pode ser aplicado? Como reconhecer estas situaes? Participantes - Descreve as classes e/ou objetos que participam no design pattern e suas responsabilidades.

17

Colaboraes - Descreve como os participantes colaboram entre si para realizar suas responsabilidades. Assim, a soluo descreve no somente a estruturas estticas, mas tambm a dinmica comportamental dos objetos e classes. Diagrama - Representao grfica do padro utilizando a tcnica de modelagem de objetos. Conseqncias - Quais os resultados obtidos com a aplicao do design pattern? O que foi resolvido, o que no foi resolvido e que design patterns pode ser aplicado neste momento? Implementao - Quais so as dicas, os macetes e as tcnicas que devem estar claras quando da implementao do padro. H questes relativas a uma linguagem especfica. Exemplos - Exemplos de sistemas reais, onde o design pattern foi aplicado e que transformaes ocorreram dentro de cada contexto. Design Patterns afins Qual design patterns tem relao com este design pattern? Quais so as diferenas importantes? Com que outros padres, este deve ser usado. (UFRJ).

3.4. Outra definio para padres de projeto Um padro um elemento de design, sendo que este mais comumente atribudo ao
arquiteto Christopher Alexander, que usa uma abordagem baseada em padro para a construo de cidades e bairros. Cada padro resolve um determinado problema adicionando uma estrutura pra o sistema. O corpo principal do padro aborda para construo de sistemas inclui com aumento, crescimento pea por pea, fundamentando experincia, e uma ateno para a qualidade de vida, e as idias de Alexander eram adotadas pelas comunidades de software, e em particular pela comunidade de programao orientada a objetos no inicio dos anos 90. O conceito de um padro muito difcil. Existem aspectos da definio que so intuitivas a soluo para o problema em contexto, ainda assim uma padro muito mais que isto. Um padro tem que ser pequeno (local), no existe organizao de estrutura do padro ou qualquer coisa assim. Os padres trabalham juntos em caminhos ricos e complexos para gerar estrutura emergente e comportamento. Uma preocupao da captura de padro individual relacionado, um padro uma encapsulaso de foras relacionadas.

18

Quando ns Aplicamos os padres, ns no podemos fazer sem preocupaes com os outros padres na linguagem. Na aplicao, eles so sempre acoplados, mas em um contexto mais longo, eles so sempre separados de algum inteiro que da a eles um contexto. Os padres so como as clulas em uma fabrica, o resultante da organizao como se fossem uma arvore ou uma floresta, os bons resultados fazem com que a de padro. (COPLIEN, 1995) clula cresa, divida e especialize. A estrutura responsvel em juntar todos esses padres leva o nome de linguagem

3. 5. A linguagem de Padro
Padro vem das linguagens de patterns, ns usamos o termo linguagem uma analogia. Ingls um idioma, como um idioma, ele inclui palavras e regras, para colocar as palavras juntas de modo q sejam significantes. O padro um idioma que inclui padro e as regras para colocar padres juntos em modos significantes, e em certa seqncia. Eles dizem como construir todo um sistema. Os padres encapsulam forcas relacionadas, assim pode focar no comercio local, coisas locais. Os idiomas de padro tratam os comportamentos emergentes de um sistema.(COPLIEN 1995).

3. 6. Seleo de Padres de GOF(Gang of Four)

A seleo de um padro de projeto um dos passos mais difceis para iniciar o uso de padres para um projeto particular. Os seguintes padres sero estudados mais detalhadamente: - Singleton Assegura que uma classe tem apenas uma instncia. - Iterator Permite o acesso aos elementos de uma agregao de uma forma seqencial sem expor a representao. - Faade Fornece uma interface uniforme a um conjunto de interfaces num subsistema. Este padro define uma interface de alto nvel que permite que os subsistemas sejam mais simples de utilizar. - Factory Method

19

Define uma interface para a criao de um objeto, mas deixa s subclasses a tarefa de definir que classes instanciarem. - Abstract Factory Fornecer uma interface para a criao de famlias de objetos relacionados, ou dependentes, sem especificar as suas classes concretas. - Observer Define uma dependncia 1-para-n entre objetos, de modo que quando o estado de um objeto alterado todos seus dependentes so notificados e atualizados automaticamente. - Adapter Converte a interface de uma classe em outra interface que os clientes esperam. O padro Adapter permite que classes que no poderiam trabalhar juntas devido a interfaces incompatveis trabalhem juntas. - Bridge Desacoplar uma abstrao de sua implementao, de modo que as duas possam variar independentemente. - Decorator Anexar responsabilidades adicionais a um objeto dinamicamente. Decorator oferecem uma alternativa flexvel ao uso de herana para estender uma funcionalidade. - Memento Sem violar o encapsulamento, capturar e externalizar o estado interno de um objeto para que o objeto possa ter esse estado restaurado posteriormente.

4. ANALISE DOS PADRES DE PROJETO SELECIONADOS 4.1. Singleton

Garante que determinada classe tenha somente um instancia e fornece um ponto global de acesso para a mesma. (GAMMA, 2005)

4.1.1 Motivao
Em muitas situaes necessrio garantir que algumas classes tenham uma e somente uma instncia. Exemplo: o gerenciador de arquivos num sistema deve ser nico.

20

4.1.2 Conseqncias
Como a classe Singleton encapsula a sua nica instncia, ela pode ter o controle total de como e quando os clientes acessam esta instncia. O padro Singleton representa uma melhoria em relao ao uso de variveis globais. A classe Singleton pode ser estendida atravs de subclasses, sendo bastante simples configurar uma aplicao para trabalhar com a extenso. A classe Singleton pode ser modificada para suportar um nmero maior de instncias, embora ainda se possa ter o controle do nmero de instncias que uma aplicao v utilizar. Uma outra maneira de implementar um Singleton atravs do uso de mtodos estticos; entretanto, a utilizao desta tcnica dificulta a mudana de um projeto para permitir um nmero maior de instncias. Alm disso, as funes estticas no so polimrficas, o que significa que as subclasses no podem redefini-las polimorficamente.(MATHIAS, 2000).

4.1.3 Exemplo
Suponha que desejemos escrever uma classe que possa ser usada por uma applet para garantir que no mais que um udio clipe possa ser executado em um dado momento. Se uma applet contiver dois trechos de cdigo que reproduzam udio clipes independentemente, ento seria possvel para ambas reproduzirem os udio clipes ao mesmo tempo. Tal ocorrncia poderia levar uma condio de erro, ou a uma situao de grande confuso, com o usurio ouvindo um mix de sons no muito agradvel. Para evitar tal situao necessrio que a classe responsvel pela reproduo de udio clipes interrompa a reproduo corrente antes de comear uma nova. Um meio de implementar essa poltica assegurar que exista uma nica instncia da classe de reproduo, e que ela seja compartilhada por todas as classes que desejem reproduzir udio clipes. Se todas as solicitaes para reproduo forem direcionadas para um nico. (MATHIAS,2000)

21

4.1.4 Aplicabilidade
Quando deva existir apenas uma instncia de uma classe e essa instncia deve dar acesso aos clientes atravs de um ponto bem conhecido. Sendo um padro de criao de objetos, o padro singleton garante que uma determinada tenha uma nica instancia durante o tempo de execuo do software. Alem disso o uso deste padro permite que essa instancia nica seja acessvel de qualquer parte do software (Objeto Global). Os objetos do tipo Singleton so criados sob demanda, ou seja, somente criados se necessrios. O uso do padro realizada atravs da implementao de um atributo e um mtodo na classe (static) mtodo utilizado para criao do objeto nico da classe. Quando acionado um atributo esttico retornado, no qual possui um apontador para o endereo do objeto no atributo esttico da classe. Caso esse objeto ainda no tenha sido criado o mtodo armazena um apontador para o endereo do objeto no atributo esttico da classe, e retorna esse endereo no atributo esttico da classe, e retorna o endereo. Assim garantindo que apenas o mtodo esttico ser usado na tarefa de criao dessa maneira o construtor dessa classe ser privado. (J2EEBrasil, 2005).

Figura 2. Estrutura do padro Singleton.

4.1.5 Estrutura
O diagrama de classes da Figura 2. mostra apenas o necessrio para a instanciao do singleton. Obviamente, a classe deve conter outros atributos e mtodos.

22

Figura 3. Diagrama de seqncias de um Singleton. A Figura 3. mostra um diagrama de seqncias que representa o processo de criao de um singleton. Quando um objeto chama o singleton pela primeira vez, realizada instanciao do singleton. Os demais acessos ao singleton iro utilizar a instncia j criada.

4.1.6 Cdigo Exemplo Singleton

4.2. Iterator
Fornecer um meio de acessar sequencialmente os elementos de um objeto agregado, sem expor sua representao subjacente.

23

4.2.1 Motivao
Um agregado de objetos, assim como uma lista deve fornecer um meio de acessar seus elementos sem necessariamente expor sua estrutura interna. Pode ser necessrio percorrer um agregado de objetos de mais de uma maneira diferente. Eventualmente necessrio manter mais de um percurso pendente em um dado agregado de objetos.

4.2.2 Conseqncias
A mera substituio de um Iterator permite caminhar numa coleo de vrias formas. Juntar a interface de caminhamento num Iterator permite retirar esta interface da coleo, simplificando assim a interface desta coleo. Vrias iteraes podem estar ocorrendo ao mesmo tempo, j que o estado de uma iterao mantido no Iterator e no na coleo.

4.2.3. Exemplo
Nos televisores os botes do controle remoto,anterior w prximo, so utilizados para percorrer os canais. Quando o espectador navega atravs desses botes pelos canais, o numero do canal no importante , apenas o programa visualizado. Se o programa visualizado na altura, no tiver interesse, o espectador pode passar ao canal seguinte, atravs do boto seguinte, sem saber o seu numero para o qual vai.( Anacleto Correia - IPS-EST Setbal)

4.2.4. Aplicabilidade
Para acessar os contedos de um agregado de objetos sem expor a sua representao interna. Para suportar mltiplos percursos de agregados de objetos. Para fornecer uma interface uniforme que percorra diferentes estruturas agregadas (suportando iterao poli frmica). outro padro de projeto relativamente simples, considerando como um padro de comportamento, muito til para prover a navegao consistente entre elementos mantidos por uma coleo ou agregado de objetos, sem que sua estrutura se torne evidente ou que seja necessrio conhecimento de sua representao interna. Stroustrup afirma que: iterators so a 24

cola que mantm containers e algoritmos juntos. [Traduo livre] (Stroustrup, 1997, p.549)Abid (JANDL, 2003). Esse padro pretende oferecer uma interface consistente para que os elementos de uma estrutura de dados possam ser adequadamente percorridos, ou seja, ele pode ser usado para prover o acesso ao contedo dessas estruturas sem violar seu encapsulamento e sem a necessidade de conhecimento da representao interna. Permite ainda que diferentes formas de navegao sejam implementadas e possibilita o controle de mltiplos percursos da navegao por uma mesma estrutura. (JANDL, 2003).

4.2.5. Estrutura

Figura 4. - Estrutura do padro Iterator.

4.2.6. Cdigo exemplo Iterator

25

4.3. Faade
Fornecer uma interface unificada para um conjunto interfaces de um subsistema, definir uma interface de nvel mais alto que torna subsistemas mais fceis de serem utilizados.

4.3.1 Motivao
Necessidade de estruturar um sistema em subsistema, facilitando o acesso e minimizando a comunicao e dependncias entre os subsistemas.

4.3.2 Conseqncias
Isola os clientes dos componentes de um subsistema, reduzindo o nmero de objetos com os quais os clientes tm que lidar, e tornando, assim, mais fcil o uso de tal subsistema.

26

Promove o fraco acoplamento entre um subsistema e os seus clientes. Esta caracterstica permite variar os componentes de um subsistema sem afetar os seus clientes. Simplifica o porte de um sistema para outras plataformas, uma vez a sua utilizao diminui a ocorrncia de alteraes em cascata em funo da necessidade de uma alterao em certo subsistema. No impede que as aplicaes utilizem diretamente as classes de um subsistema caso necessitem faz-lo. Assim, pode-se escolher entre a facilidade de uso e uma maior flexibilidade na manipulao das funcionalidades fornecidas por um subsistema.

4.3.3 Exemplo
Os clientes encontram uma fachada (front - Office) ao encomendar a partir de um contato. O cliente telefona para um numero e fala com o funcionrio d atendimento ao publico. O funcionrio age como uma fachada, fornecendo uma interface dos servios de recepo de encomendas, de cobrana expedio de encomendas.

4.3.4 Aplicabilidade
Fornecer uma interface simples e unificada para um sistema complexo, desacopla os subsistemas dos clientes, promovendo-se a independncia e portabilidade dos subsistemas, estruturando o sistema em camadas. Estruturar um sistema em subsistemas ajuda a reduzira complexidade. Um objetivo comum a todos os projetos minimizar a comunicao e as dependncias entre os subsistemas que compem uma aplicao. Uma maneira de alcanar este objetivo introduzir um objeto faade (fachada). (MATHIAS, 2000).

4.3.5 Estrutura

Figura 5. Estrutura do padro Faade. 27

A Figura 5 - mostra um diagrama de classes que ilustra a estrutura geral do padro Faade. O objeto Client interage com o objeto Faade, que fornece a funcionalidade necessria para interao com o restante dos objetos. Quando alguma funcionalidade adicional for necessria para alguns clientes, a melhor alternativa que o objeto Faade fornea um mtodo separado para que seja possvel acessar diretamente o objeto responsvel por tal funcionalidade, ao invs de inclui - l na interface principal. (MATHIAS, 2000).

4.3.6. Cdigo exemplo Faade

4.4. Factory Method

Definir uma interface para criar um objeto, mas deixar que as subclasses decidam que classe instanciar. O Factory Method permite adiar a instanciao para as subclasses.

4.4.1. Motivao
Em muitas situaes, uma aplicao necessita criar objetos cujas classes fazem parte de uma hierarquia de classes, mas no necessita ou no tem como definir qual a subclasse a ser

28

instanciada. O Factory Method usado nesses casos e decide com base do contexto, qual das subclasses ativar.

4.4.2. Conseqncias
O CreationRequestor torna-se independente da classe do objeto (ConcreteProductX) instanciado, podendo trabalhar com quaisquer classes concretas definidas pelo framework. O tipo dos produtos que sero manipulados pela aplicao pode ser mudado dinamicamente.

4.4.3. Exemplo
Suponha que estejamos desenvolvendo uma extenso da classe Socket com o objetivo de codificar streams de bytes enviados por uma conexo socket e de decodificar streams de bytes recebidos por conexes de mesma natureza. Chamaremos esta classe de EncryptedSocket. A classe EncryptedSocket dever suportar mltiplos algoritmos de codificao. Em funo das restries legais impostas pelo governo dos EUA importao e exportao de algoritmos de codificao, a classe EncryptedSocket dever ser mantida independente das classes que implementam os algoritmos de codificao e decodificao. O uso de mltiplos algoritmos de codificao e decodificao, sem que a classe encryptedsocket tenha que conhecer antecipadamente as classes que encapsulam tais algoritmos, nos sugere a aplicao do padro Factory Method para solucionar este problema.

4.4.4. Aplicabilidade
Quando uma classe no puder antecipar as classes dos objetos que ele precisa criar. Quando uma classe tiver que delegar s suas subclasses a responsabilidade pela criao de objetos de uma aplicao. Isso permitir localizar nas subclasses o conhecimento necessrio criao dos objetos.

29

4.4.5. Estrutura

Figura 6 Estrutura do Padro Factory Method. A Figura 6 mostra um diagrama que ilustra os papis das classes e das interfaces que compem o padro Factory Method.

4.4.6. Cdigo Exemplo

30

4.5. Abstract Factory

Fornecer uma interface para a criao de famlias de objetos relacionados, ou dependentes, sem especificar as suas classes concretas.

4.5.1 Motivao
Em muitas situaes uma aplicao cliente precisa criar determinados objetos cuja construo efetiva s definida em tempo de execuo. A aplicao cliente no deve se preocupar com a criao dos objetos.

4.5.2. Conseqncias
As classes concretas que implementam os componentes visuais so independentes das classes que as usam, dado que a fbrica abstrata encapsula o processo de criao de tais componentes visuais. Inserir novas classes que dem suporte a novas plataformas uma tarefa simples. Uma classe que represente uma fbrica concreta usualmente referenciada em apenas um ponto do framework. De modo similar, bastante simples alterar uma fbrica concreta para tratar de uma nova plataforma a ser adicionada ao framework. Ao forarmos os clientes a usarem as fbricas concretas para a criao dos componentes visuais, o padro Abstract Factory assegura que eles usaro um conjunto de objetos consistentes com a plataforma com a qual desejam interagir. A principal deficincia do padro Abstract Factory o excesso de trabalho necessrio para criar um conjunto de classes que d suporte a uma nova plataforma.

4.5.3. Exemplo
Um programa tem por objetivo realizar diagnsticos remotos em computadores para um fabricante de equipamentos. Atravs dos anos, o fabricante em questo produziu computadores com substanciais diferenas nas suas respectivas arquiteturas. Nos equipamentos mais antigos foram usados chips de CPU da Enginola, que so baseados na tradicional arquitetura CISC. Desde ento, o nosso fabricante produziu computadores baseados nas suas prprias arquiteturas RISC, chamadas de Ember, SuperEmber e 31

UltraEmber. Os componentes principais destas vrias arquiteturas executam funes similares, porm possuem conjuntos de componentes distintos.

4.5.4. Aplicabilidade
O sistema deve ser independente de como seus produtos so criados, compostos ou representados O sistema deve ser configurado como um produto de uma famlia de mltiplos produtos A famlia de objetos-produto projetada para ser usada em conjunto deseja-se revelar apenas a interface da biblioteca de classes produto e no a sua implementao.

4.5.5. Estrutura

Figura 7 Estrutura do Padro Abstract Factory. A Figura 7 mostra um diagrama de classes que ilustra o papel de cada classe que participa do padro Abstract Factory.

4.5.6. Cdigo Exemplo

32

33

4.6. Observer
Define uma dependncia 1-para-n entre objetos, de modo que quando o estado de um objeto alterado todos seus dependentes so notificados e atualizados automaticamente.

4.6.1. Motivao
Suponha que voc deseja fornecer vrias vises distintas de um mesmo objeto que funciona como um repositrio de dados. Cada viso criada por um objeto observador independente. Caso cada observador seja diretamente conectado ao repositrio, isto criar uma dependncia do repositrio com relao aos diferentes observadores, o que lhe reduzir a reusabilidade e flexibilidade. O padro Observer descreve uma forma de manuteno destes relacionamentos de modo que observadores e repositrios sejam facilmente substitudos.

4.6.2. Conseqncias
Tudo que o objeto observado tem que saber que ele observado por uma coleo de observadores, todos implementando uma interface muito simples (ObserverIF). Como o objeto observado no precisa conhecer a classe concreta de nenhum dos seus observadores, o acoplamento entre o objeto observado e seus observadores mnimo. Diferentemente de uma solicitao ordinria, a notificao que um objeto observado envia no precisa especificar o seu receptor. A notificao transmitida automaticamente para todos os observadores registrados; implementando, assim, um mecanismo de broadcasting. Como um observador no tem conhecimento da presena de outros observadores, no possvel avaliar priori o custo global de uma mudana no estado do objeto observado. Desta forma, uma alterao aparentemente simples no objeto observado pode disparar uma cascata de modificaes nos objetos observadores e nos seus respectivos objetos dependentes.

4.6.3. Exemplo
Seja uma empresa que produz detectores de fumaa, sensores de movimento e outros dispositivos de segurana. Para aproveitar novas oportunidades de mercado, esta empresa planeja introduzir uma nova linha de dispositivos. Tais dispositivos devem estar aptos a 34

enviar sinais para uma placa de segurana que possa ser instalada na maioria dos computadores comercializados atualmente. O objetivo permitir que as empresas que desenvolvem sistemas de monitoramento possam integrar estes novos dispositivos nas suas solues. Para facilitar a tarefa de integrao, a API que ser fornecida com a nova linha de dispositivos foi implementada com o padro Observer. (MATHIAS, 2000).

4.6.4. Aplicabilidade
Quando uma abstrao tem dois aspectos, um dependente do outro. Encapsulando estes aspectos em objetos distintos ser possvel vari-los e reutiliz-los independentemente. Quando uma mudana em um objeto exigir mudanas em outros e no soubermos quantos objetos precisam ser modificados. Quando quisermos que um objeto seja capaz de notificar outros objetos sem que tenha que ter conhecimento, ou usar informaes, de tais objetos. Em outras palavras, quando quisermos manter baixo o acoplamento entre tais objetos.

4.6.5.Estrutura

Figura 8 Estrutura do Padro Observer. A Figura 8 mostra um diagrama de classes com os principais componentes do padro Observer.

35

4.6.6. Cdigo Exemplo

4.7. Adapter
Converte a interface de uma classe em outra interface que os clientes esperam. O padro Adapter permite que classes que no poderiam trabalhar juntas devido a interfaces incompatveis trabalhem juntas.

4.7.1. Motivao

36

Em algumas situaes, a interface oferecida por um toolkit, projetada para ser reutilizada no pode ser usada numa aplicao porque sua interface no corresponde interface especfica Muitas vezes uma ferramenta ou uma classe de biblioteca no pode ser usada, porque sua interface no a requerida pela aplicao. No se pode mudar a interface, porque no se dispe do cdigo fonte. Mesmo que se tivesse, no interessante mudar a biblioteca a cada aplicao. Padro Adapter fornece um objeto com uma nova interface que se adapta interface de outro objeto, permitindo a colaborao. Anlogo a adaptadores de tomadas eltricas.

4.7.2. Conseqncias
Um adaptador de classe no funciona se quisermos adaptar uma dada classe e todas as suas subclasses. possvel substituir algum comportamento do Adaptee, uma vez que Adapter uma subclasse de Adaptee. Introduz somente um objeto intermedirio, no sendo necessrio endereamento indireto adicional at se chegar ao Adaptee.

4.7.3.Exemplo
Um editor de desenhos permite aos usurios desenhar e arranjar elementos grficos (linhas, polgonos, textos, etc.) em figuras e diagramas. A abstrao chave do editor de desenhos o objeto grfico, no qual tem uma forma editavel e pode desenhar a si prprio, essa interface para objeto grfico chama se Shape, e esse editor define uma subclasse shape para cada tipo de objeto grfico.

4.7.4.Aplicabilidade
Situaes nas quais as classes que devem interagir no tm interfaces compatveis Adaptador de objetos aplicvel nos casos em que no possvel adaptar as classes existentes atravs de subclasses. Permite a um nico Adapter trabalhar com muitos Ataptees. 37

 difcil redefinir o comportamento de um Adaptee. Para isso necessria a criao de subclasses.

4.7.5. Estrutura

Figura 9 Estrutura do padro Adapter.

4.7.6. Cdigo Exemplo

38

4.8. Bridge
Desacoplar uma abstrao de sua implementao, de modo que as duas possam variar independentemente.

4.8.1.Motivao
Em alguns casos, uma abstrao pode ter mais de uma implementao possvel e herana no suficientemente flexvel porque liga de forma permanente a abstrao da implementao.

4.8.2. Conseqncias
Desacoplar a interface da implementao possvel estender as hierarquias de Abstraction e Implementor de forma independente. capaz de ocultar detalhes de implementao dos clientes

4.8.3. Exemplos
Imagine uma subclasse IconWindow de window que especializa abstrao Window para cones. Para suportar IconWindow para ambas as plataformas, temos que implementar duas classes novas, XIconWindow e PMIconWindow. E ainda teremos que definir duas classes para cada tipo de janela. O Bridge trata desses problemas colocando a abstrao Window e sua implementao em hierarquias de classes separadas para interfaces de janelas.e uma hierarquia separada para implementaes de janelas especificas da plataformas tendo como sua raiz WindowImp. Todas as operaes das subclasses de window so implementadas em termos das operaes abstratas da interface WindowImp, desacoplando assim as abstraes de janelas das varias implementaes especificas para cada plataforma. Sendo assim Window e WindowImp formam uma ponte entre abstrao e sua implementao, permitindo assim variaes de formas independentes.

39

4.8.4. Aplicabilidade
Deseja-se evitar o vnculo permanente da abstrao e sua implementao. Isso pode ser necessrio, por exemplo, quando a implementao deve ser definida ou alterada em tempo de execuo. Tanto as abstraes como suas implementaes devem ser extensveis por meio de subclasses. Atravs do padro Bridge possvel combinar as diferentes abstraes e implementaes e estend-las independentemente. Deseja-se ocultar completamente a implementao dos clientes. necessrio compartilhar uma implementao entre mltiplos objetos.

4.8.5. Estrutura

Figura 10. Estrutura do padro Bridge

4.9. Decorator
Anexar responsabilidades adicionais a um objeto dinamicamente. Decorator oferecem uma alternativa flexvel ao uso de herana para estender uma funcionalidade.

4.9.1 Motivao
Uma classe TextView mostra um texto em uma janela, queremos incrementar a janela com uma borda e/ou uma barra de rolagem, pode-se usar herana, mas muitas subclasses incrementos no podem ser acrescentados/removidos em execuo.

40

4.9.2. Conseqncias
Maior flexibilidade que herana: decoradores podem ser retirados e acrescentados em execuo, Mas ponteiros para a TextView continuam enxergando o objeto sem decorao. No h necessidade de criao de inmeras subclasses. Um decorador e seus componentes no so iguais: operaes de igualdade falham. Muitos objetos pequenos so criados.

4.9.3. Exemplo
Suponhamos que tenhamos um objeto Textview que exibe texto numa janela. como padro, textview no tem barras de rolamento por que nem sempre a necessitamos, quando as necessitamos, poderemos usar um scrollDecorator para acrescenta - ls. Suponhamos tambm, que queiramos acrescentar uma borda preta espessa ao redor do objeto TextView. Podemos usar um objeto BorderDecorator para esta finalidade.(GAMMA, 2005).

4.9.4. Aplicabilidade
Para adicionar responsabilidades a objetos individuais de forma dinmica e transparente, isto , sem afetar outros objetos. Para retirar responsabilidades. Quando a extenso atravs do uso de subclasses no pratica. s Vezes, um grande numero de extenso independentes possvel e isso poderia produzir uma subclasses para suportar cada combinao.

4.9.5. Estrutura

Figura 11. Estrutura do padro decorator 41

4.9.6. Cdigo Exemplo

4.10. Memento
Sem violar o encapsulamento, capturar e externalizar o estado interno de um objeto para que o objeto possa ter esse estado restaurado posteriormente. (GAMMA, 2005).

4.10.1. Motivao
Algumas vezes necessrio registrar o estado interno de um objeto. Isso necessrio na implementao de mecanismos de checkpoints e de desfazer (operaes) que permitem aos usurios retroceder de operaes-tentativas ou recuperar-se de erros. Deve-se salvar informao de estado em algum lugar, de tal modo que possa restaurar os objeto aos seus estados prvios. Os objetos normalmente encapsulam parte ou todos os seus estados, tornando-se inacessveis a outros objetos e impossveis de serem salvos externamente. Expor este estado violaria o encapsulamento, o que pode comprometer a confiabilidade e a extensibilidade da aplicao.

42

4.10.2. Conseqncias
Preservao das fronteiras de encapsulamento evita a exposio de informao que somente um originador deveria administrar, mas deve ser armazenada fora do originador, protege outros objetos de aspectos internos e complexos do originador. Ele simplifica o originador em outros projetos de preservao do encapsulamento, mantem as verses do estado interno solicitadas pelos clientes. Coloca toda a carga de administrao do armazenamento sobre o originador. Mementos podem produzir custos adicionais considerveis se o originador tiver de copia grandes quantidades de informao para armazenar o memento. Difcil em algumas linguagens garantir que somente o originador possa acessar o estado do memento. Um carataker responsvel por deletar o memento do qual ele tem a custodia. O carataker no tem idia do volume ocupado pelo estado do memento. (GAMMA, 2005).

4.10.3. Exemplo
Um editor grfico que suporta conectividade entre objetos. Um usurios pode conectar dois retngulos com uma linha, e os retngulos permanecem conectados quando o usurio mover qualquer um deles. O editor assegura que a linha estique para manter a conexo.

4.10. 4. Aplicabilidade
Quando um snapshot do (parte do) estado de um objeto precisa ser armazena da para que ele possa ser restaurado ao seu estado original posteriormente Quando uma interface direta para se obter esse estado iria expor detalhes de implementao e quebrar o encapsulamento do objeto

43

4.10.5. Estrutura

Figura 12. Estrutura padro Memento

4.10.6. Cdigo Exemplo

44

5. CONLUSES
Depois de estudar e conhecer um pouco mais sobre cada um dos padres selecionados, comea se a pensar em estudos posteriores onde possa - se aprofundar e comear absorver informaes mais detalhadas sobre o tema, consegui -se entender que um padro de projeto consegue estruturar e organizar um projeto em desenvolvimento sendo ele bem aplicado, por exemplo, no caso do padro Singleton faz com que uma varivel ou um objeto seja exclusivo imaginando q eu tenha um abjeto com nome de quadrado azul, isso significa o que depois de implementado com o singleton. A partir de que uma vez criado nenhum outro objeto pode ser criado ou seja os demais objetos criados sero clone de quadrado azul. Assim garantindo uma proteo maior, desde que seja ele usado no lugar certo. Foi abordado tambm um outro padro interessante entre todos os padres estudado, o padro chamado Factory Method, proporciona ao programador definir classses e subclasses atravs de uma hierarquia, mas a parte interessante que somente usada quando for necessria, por exemplo eu tenho duas classes a primeira classe recebe o nome de Laranja e tem suas sub-classes com o nome de tipoe a segunda preo, e existe uma outra classe com o nome de Alface que tem sua sub-classe com o nome de Tipo, assim no caso de necessitar buscar e trazer maiores informaes sobre o tipo ou preo da laranja as subclasses so chamadas caso contrario no, e isso se repete no caso da classe alface, se necessario maiores informaes suas sub-classes so chamadas caso contrario elas no participam, so sub-classe de tal classe mas de tal forma no to dependentes. Estudando os padres consegue - se notar tambm que, o uso dos padres de projetos frequentemente pode trazer experincia e muito conhecimento adquiri se , pois esse padres so solues testadas e que so os problemas mais freqentes que um programador enfrenta no seu dia a dia. E eles se repetem nas mais diversas configuraes de software, e podem ser compartilhados entre a classe de desenvolvedores de software. Conclui - se tambm que, Escrever um padro de projeto e custoso e muito trabalhoso, sendo que de maneira iterativa e na maioria dos casos envolve outros padres aplicados no projeto, mas apesar de todos os fatores desfavorveis, um esforo q vale muito a pena, para que um dia todos os desenvolvedores de software possam utilizar os padres de projetos.

45

6. REFERNCIAS BIBLIOGRFICAS
COPLIEN, James O.; HARRISON, Neil B.Organizational Patterns of agile software development. Disponvel em:< http://www.easycomp.org/cgi-bin/OrgPatterns?BookOutline> Acesso em 10 nov. 2006. GAMMA, Erick; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Padres de projeto. Porto Alegre, RS Bookman, 2005. JANDL, Peter J. Mais Java. So Paulo: Futura, 2003. J2EEBrasil. Padres de Projeto: O padro Singleton. Disponvel em:

<http://www.jspbrasil.com.br/pdf/tutoriais/tutorial_004_001.pdf >. Acesso em: 18 jun. 2006. JUNQUEIRA, Alvaro R. B. Design Patterns: Conceitos e Aplicaes. Disponvel em: <http://www.dcc.ufrj.br/~schneide/PSI_981/gp_6/design_patterns.html>. Acesso em: 12 set. 2006 MACKENZIE. Uma Abordagem 3D para a Visualizao de Padres de Projeto. Disponvel em: < http://users.exa.unicen.edu.ar/~teyseyre/papers/camsbes97.pdf>. Acesso em: 15 jun. 2006. MATHIAS, Ivan Filho. Apostila Design Patterns. Disponvel em: <http://www.ic.unicamp.br/~vanini/mc746/padroesdeprojeto.pdf>. Acesso em 10 ago. 2006. WIKIPDIA. Padres de projeto. Disponvel em: <http://pt.wikipedia.org/wiki/Padr%C3%B5es_de_Projeto > Acesso em 21 jun. 2006.

. 46

7. ASSINATURAS

________________________________
Luis Francisco Thomazini Neto

________________________________
Peter Jandl Jr.

47