tópicos especiais de programação orientada a objetos · java tópicos especiais ... 8...

JAVATópicos Especiais de Programação

Orientada a Objetos

1

sexta-feira, 9 de novembro de 12

PADRÕES DE PROJETO

2


INTRODUÇÃO

3

Conhecido em inglês por Design Pattern. Design é uma palavra de origem alemã que significa projeto.

Padrão é uma maneira testada ou documentada de alcançar um objetivo qualquer.

Os padrões visam facilitar a reutilização de soluções de desenho e na fase de projeto. Utilizam um vocabulário comum de desenho, facilitando comunicação, documentação e aprendizado.

Os padrões são muito comuns nas áreas de engenharia. Exemplos de padrões: ISO, ABNT, etc.


INTRODUÇÃO

4

Padrões para alcançar objetivos na engenharia de software usando classes e métodos em linguagens orientadas a objeto.

Inspirado em “A Pattern Language” de Christopher Alexander, em 1977, que diz “Um padrão descreve um problema que ocorre inúmeras vezes em determinado contexto, e descreve ainda a solução para esse problema, de modo que essa solução possa ser utilizada sistematicamente em distintas situações.”


VANTAGENS DO USO DE PADRÕES EM SISTEMAS

5

•Ajuda a construir um software confiável com arquiteturas testada e perícia acumulada pela indústria.

•Promovendo a reutilização de projetos em futuros sistemas.

•Ajuda a identificar equívocos comuns e armadilhas que ocorrem ao construírem sistemas.

•Apoia o projeto de sistemas independentemente da linguagem em que eles, em última instância, serão implementados.

•Encurtando a fase de projeto no processo de desenvolvimento de um software.


VANTAGENS DO USO DE PADRÕES EM SISTEMAS

6

•Estabelecendo um vocabulário comum de projeto entre os desenvolvedores. Faz o sistema ficar menos complexo ao permitir que se fale em um nível mais alto de abstração

•Ajuda na documentação e na aprendizagem. Conhecendo os padrões de projeto torna mais fácil a compreensão de sistemas existentes. Para o GoF: "As pessoas que estão aprendendo POO frequentemente reclamam que os sistemas com os quais trabalham usam herança de forma complexa e que é difícil de seguir o fluxo de controle. Geralmente a causa disto é que eles não entendem os padrões do sistema“.

•Aprender os padrões ajudam um novato a agir mais como um especialista.


CARACTERÍSTICAS DE UM PADRÃO

7

Encapsulamento: um padrão encapsula um problema/solução bem definida. Ele deve ser independente, específico e formulado de maneira a ficar claro onde ele se aplica.

Generalidade: todo padrão deve permitir a construção de outras realizações a partir deste padrão.

Equilíbrio: quando um padrão é utilizado em uma aplicação, o equilíbrio dá a razão, relacionada com cada uma das restrições envolvidas, para cada passo do projeto. Uma análise racional que envolva uma abstração de dados empíricos, uma observação da aplicação de padrões em artefatos tradicionais, uma série convincente de exemplos e uma análise de soluções ruins ou fracassadas pode ser a forma de encontrar este equilíbrio.


CARACTERÍSTICAS DE UM PADRÃO

8

Abstração: os padrões representam abstrações da experiência empírica ou do conhecimento cotidiano.

Abertura: um padrão deve permitir a sua extensão para níveis mais baixos de detalhe.

Combinatoriedade: os padrões são relacionados hierarquicamente. Padrões de alto nível podem ser compostos ou relacionados com padrões que endereçam problemas de nível mais baixo.


ELEMENTOS DE UM PADRÃO

9

Nome: uma descrição da solução, mais do que do problema ou do contexto.

Exemplo: uma ou mais figuras, diagramas ou descrições que ilustrem um protótipo de aplicação.

Contexto: a descrição das situações sob as quais o padrão se aplica.

Problema: uma descrição das forças e restrições envolvidos e como elas interagem.

Solução e Consequências: descreve os elementos que compõem o projeto, seus relacionamentos, responsabilidades e colaborações. Um padrão deve ser uma solução concreta, ele deve ser exprimido em forma de gabarito (algoritmo) que, no entanto pode ser aplicado de maneiras diferentes. Todo padrão deve relatar quais são as suas consequências para que possa ser analisada a solução alternativa de projetos e para a compreensão dos benefícios da aplicação do projeto.


PADRÕES DE DESENVOLVIMENTO DE SISTEMAS

10

"A Pattern Language"de Christopher

Alexander (1970)

Padrão GRASP

Padrão GoF (Gang of Four)

(1995)

Padrão MVC (Model View Controler)

Padrão J2EE

Padrão J2EE


PADRÕES DE DESENVOLVIMENTO DE SISTEMAS

11

PADRÃO GoFPrincípios de Projetos de OO

(fase de desenvolvimento e implantação)

PADRÃO GRASP(General Responsability and Assignment Software Patterns)

Princípios de Projetos de OO (Atribuição de responsabilidades em objetos


O PADRÃO GANG OF FOUR (GOF)

12

Por meio dos trabalhos iniciados por Alexander, profissionais de software começaram a incorporar esses princípios na criação das primeiras documentações de padrões de projetos como um guia para desenvolvedores iniciantes. O resultado prático foi a publicação de Design Patterns : Elements of Reusable Object-Oriented Software, em 1995, por Eric Gamma, Richard Helm , Ralph Johnson e John Vlissides (Turma dos Quatro, Gang of Four).

Este livro é a referência principal no assunto para a comunidade de software. Nele são descritos 23 padrões que foram baseados na experiência dos autores.


ORGANIZAÇÃO DO PADRÃO GOF

13Com

portamento*(1

1).

Estrutura*(6

).

Criação*(5

).Factory*Method.

Abstract*Factory.

Builder.

Prototype.

Singleton.

Class/Object*Adapter.

Bridge.

Composite.

Decorator.

Facade.

Flyweight.

Proxy.

Interpreter.

Template*Method.

Chaing*of*Responsability.

Command.

Iterator.

Mediator.

Memento.

Observer.

State.

Strategy.

Visitor.

Referem&se(ao(processo(de(instanciação(das(classes(ou(criação(dos(objetos.8

Caracterizam(a(forma(com(que(as(classes(e(os(objetos(se(interagem(e(compartilham(as(responsabilidades8

Tratam(a(composição(das(classes(e(objetos,(e(o(relacionamento(entre(esses(elementos8


CLASSIFICAÇÃO

14

Con

strução*

Respon

sabilid

ade*

Operações*

Interfaces*

Extensões*

Adapter*

Facade*

Composite*

Bridge*Singleton*

Observer*

Mediator*

Proxy*

ChainEofEResponsability*

Flyweight*

Builder*

FactoryEMethod*

AbstractEFactory*

Prototype*

Memento*

TemplateEMethod*

State*

Strategy*

Command*

Interpreter*

Decorator*

Iterator*

Visitor*


PADRÃO DE INTERFACE

15

1.#Adapter+

Converte(a(interface(de(uma(classe(em(outra(interface(

esperada(pelos(clientes.+

2.#Façade+

Oferecer(uma(interface(única(de(nível(mais(elevado(

(Fachada)(para(um(conjunto(de(interfaces(de(um(subsistema.=

Separação(do(sistema(em(camadas.+

3.#Composite+

Permitir(o(tratamento(de(objetos(

individuais(e(composições(

desses(objetos(de(maneira(

uniforme((como(se(todos(fossem(componentes).+

4.#Brigde+

Desacoplar(uma(abstração(de(sua(implementação(para(que(os(dois(possam(variar(independentemen

te.=

Swing(possui(diversos(Look(and(feels(do(Java(

Swing.+


EXEMPLO FAÇADE

16


EXEMPLO ADAPTER

17


EXEMPLO ADAPTER

18


PADRÃO DE ESTRUTURA: 6. ADAPTER

19


PADRÃO DE RESPONSABILIDADES

20

5.#Proxy)

Prove&um&substituto&ou&

ponto&através&do&qual&

um&objeto&possa&

controlar&o&acesso&a&

outro.&Em&sua&forma&

mais&geral,&é&uma&classe&

que&funciona&como&uma&

interface&para&outra&

classe.;

6.#Chain#of#Responsability)

Compõe&objetos&em&

cascata&para,&através&

dela,&delegar&uma&

requisição&até&que&um&

objeto&a&sirva.&

Mecanismo&de&herança&

nas&linguagens&

orientadas&a&objeto.;

7.#Flyweigh)

Usa&compartilhamento&

para&suportar&

eficientemente&grandes&

quantidades&de&objetos&

complexos.&Não&existem&

ponteiros&para&os&

métodos&do&dado.&No&

processador&de&texto&&

cada&caractere&

representa&um&objeto&de&

uma&família.&ResolveHse&

com&muitas&informações&

repetidas.)



21

8.#Singleton,

Garante'que'uma'classe'só'tenha'uma'única'instância,'e'prover'um'ponto'de'acesso'global'a'ela.'Exemplo,'classe'de'conexão'a'banco'de'

dados.>

9.#Observer,

Definir'uma'dependência'umBparaBmuitos'entre'objetos'para'que'quando'um'objeto'mudar'de'estado,'os'seus'dependentes'sejam'notificados'e'atualizados'

automaticamente.'Exemplo'Listeners,'implementam'uma'interface'observable.>

10.#Mediator,

Definir'um'objeto'que'encapsula'a'forma'como'um'conjunto'de'objetos'interagem.'Cada'objeto'participante'conhece'o'mediador'mas'ignora'a'existência'dos'outros'objetos.'O'mediador'conhece'cada'um'dos'objetos'participantes.,



22

8.#Singleton,

Garante'que'uma'classe'só'tenha'uma'única'instância,'e'prover'um'ponto'de'acesso'global'a'ela.'Exemplo,'classe'de'conexão'a'banco'de'

dados.>

9.#Observer,

Definir'uma'dependência'umBparaBmuitos'entre'objetos'para'que'quando'um'objeto'mudar'de'estado,'os'seus'dependentes'sejam'notificados'e'atualizados'

automaticamente.'Exemplo'Listeners,'implementam'uma'interface'observable.>

10.#Mediator,

Definir'um'objeto'que'encapsula'a'forma'como'um'conjunto'de'objetos'interagem.'Cada'objeto'participante'conhece'o'mediador'mas'ignora'a'existência'dos'outros'objetos.'O'mediador'conhece'cada'um'dos'objetos'participantes.,


EXEMPLO CHAIN OF RESPONSABILITY

23


EXEMPLO FLYWEIGH

24


EXEMPLO OBSERVER

25


PADRÃO DE CRIAÇÃO: 5. SINGLETON

26

Garante que uma classe só tenha uma única instância, e prover um ponto de acesso global a ela.

Por exemplo, seu sistema pode ter apenas um gerenciador de janelas, ou gerenciador de impressão, ou então um único ponto de acesso ao banco de dados. A maneira mais fácil de se fazer uma classe que possua uma única instância dela mesma é utilizar uma variável estática na classe, onde será guardada a referência para a instância corrente.


PADRÃO DE CRIAÇÃO: 5. SINGLETON

27

A omissão do termo synchronized tornaria a classe não segura na execução de Threads. Este termo obriga que somente uma thread de cada vez acesse esse método.


PADRÃO DE CONSTRUÇÃO

28

11.#Builder+

Separar&a&construção&de&objeto&complexo&da&

representação&para&criar&representações&

diferentes&com&mesmo&processo.9

12.#Factory#Method+

Define&uma&interface&para&criar&um&objeto&mas&deixar&que&

subclasses&decidam&que&classe&instanciar.9

13.#Abstract#Factory+

Provê&interface&para&criar&famílias&de&objetos&relacionados&ou&dependentes&sem&

especificar&suas&classes&concretas+


PADRÃO DE CONSTRUÇÃO

29

14.$Prototype,

Especifica)tipos)a)criar)usando)uma)instância)como)protótipo)e)criar)novos)objetos)ao)copiar)

este)protótipo.7

15.$Memento,

Externaliza)o)estado)interno)de)um)objeto)para)que)o)objeto)possa)

ter)esse)estado)restaurado)

posteriormente.7


EXEMPLO FACTORY METHOD

30

Definir uma interface para criar um objeto mas deixa que subclasses decidam que classe instanciar.

Tem sua utilização em frameworks (p.ex. framework Ant e o Jakarta Commons).O padrão Factory Method é caracterizado por retornar uma instância dentre

muitas possíveis classes, dependendo dos dados providos a ele. Geralmente, todas as classes que ele retorna têm uma classe pai e métodos em comum, mas cada um executa tarefas diferentes e é otimizado para diferentes tipos de dados.


PADRÃO DE CRIAÇÃO: 1. FACTORY METHOD

31


EXEMPLO ABSTRACT METHOD

32

Prover interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.

Pode ser utilizado na implementação de um toolkit que disponibilize controles que funcionem em diferentes interfaces gráficas (p. ex. informando ao factory que quer que seu programa se pareça com o Windows e ele retorna a fábrica GUI que retorna os objetos relativos ao Windows).

Por meio de implementação de uma classe abstrata que declara uma interface genérica para criação dos controles visuais e de uma classe abstrata para criação de cada tipo de controle. O comportamento específico, de cada um dos padrões tecnológicos contemplados, é implementado através de uma classe concreta. O aplicativo, interage com o toolkit através das classes abstratas sem ter conhecimento da implementação das classes concretas.


EXEMPLO ABSTRACT METHOD

33


EXEMPLO BUILDER

34

Tem a finalidade de separar a construção de um objeto complexo de sua representação para que o mesmo processo de construção possa criar representações diferentes.

É comparado com o padrão Abstract Factory pois ambos podem ser utilizados para a construção de objetos complexos. A principal diferença entre eles é que o Builder constrói objetos complexos passo a passo e o Abstract Factory constrói famílias de objetos, simples ou complexos, de uma só vez.


EXEMPLO BUILDER

35


EXEMPLO PROTOTYPE

36

Especifica os tipos de objetos a serem criados usando uma instância como protótipo e criar novos objetos ao copiar este protótipo.

Este padrão permite que um cliente crie novos objetos ao copiar objetos existentes.

Uma vantagem de criar objetos deste modo é poder aproveitar o estado existente de um objeto.

Inicia com uma classe iniciada e instanciada que copia ou gera um clone dela para se fazer novas instâncias, ao invés de se criar novas instâncias.


EXEMPLO PROTOTYPE

37


PADRÃO DE OPERAÇÕES

38

16.$Template$Method0

Define%o%esqueleto%de%um%algoritmo%dentro%de%uma%operação,%deixando%alguns%passos%a%serem%preenchidos%pelas%subclasses:

17.$State0

Permitir%a%um%objeto%alterar%o%seu%

comportamento%quanto%o%seu%estado%interno%

mudar.:

18.$Strategy0

Definir%uma%família%de%algoritmos,%encapsular%cada%um,%e%fazêBlos%intercambiáveis.0


PADRÃO DE OPERAÇÕES

39

19.$Command+

Permite'que'objetos'deste'tipo'tenham'tais'ações'executadas'sem'que'conheçamos'o'tipo'de'tais'objetos'ou'a'natureza'das'ações.9

Permite'enfileirar'ações'para'processamento'em'outro'momento.9

20.$Interpreter+

Dada'uma'linguagem,'definir'uma'

representação'para'sua'gramática'junto'com'um'

interpretador.9Extensão'do'Command,9


EXEMPLO STATE

40

Desconectado* Conectado* Transmitido*


EXEMPLO STRATEGY

41

Se#Guerra#e#Inflação#>#Meta1

Estratégia#C1

Se#Guerra#e#Recessão1 Estratégia#B1

Outros#Cenários1 Estratégia#A1


DIFERENÇAS ENTRE STATE, STRATEGY E COMMAND

42

State representa um estado(substantivo) e geralmente está menos accessível (a mudança de estado pode ser desencadeada por outro estado)

Strategy representa um comportamento(verbo) e é escolhida dentro da aplicação(a ação pode ser desencadeada por ação do cliente ou estado)

Command representa uma ação escolhida e iniciada por um cliente externo (usuário) .


PADRÃO DE EXTENSÃO

43

21.$Decorator,

Anexar'responsabilidades'

adicionais'a'um'objeto'dinamicamente.5

Oferece'uma'alternativa'flexível'ao'uso'de'

herança'para'estender/adicionar'novas'funcionalidade.5

22.$Iterator,

Provê'uma'maneira'de'acessar'elementos'de'um'objeto'agregado'sequencialmente'sem'expor'sua'representação'

interna.'É'implementado'nas'coleções'do'Java'por'meio'do'método'

iterator()'de'Collection,'5Interator()'é'um'

exemplo'de'um'Factory'Method.5

23.$Visitor,

Representa'uma'operação'a'ser'realizada'sobre'os'elementos'de'uma'estrutura'de'objetos.'Define'uma'nova'

operação'sem'mudar'as'classes'dos'elementos'nos'quais'opera.'Estende'uma'aplicação'com'novas'operações'sem'que'seja'necessário'alterar'a'

interface'existente.'Se'a'estrutura'muda'muito,'não'deve'ser'utilizado.,


EXEMPLO DECORATOR

44


EXEMPLO VISITOR

45

Representa uma operação a ser realizada sobre elementos da estrutura de um objeto. O Visitor permite que se crie um nova operação sem que se mude a classe dos elementos sobre as quais ela opera. É uma maneira de separar um algoritmo da estrutura de um objeto. Um resultado prático é a habilidade de adicionar novas funcionalidades a estruturas de um objeto pré-existente sem a necessidade de modificá-las.


EXEMPLO ITERATOR

46


BIBLIOGRAFIA

47

•Introdução ao Java, Daniel Destro do Carmo•Use a Cabeça Java, Kathy Sierra e Bert Bates•Use a Cabeça Padrões de Projetos, Eric Freeman e Elisabeth Freeman•Certificação Sun para Programador Java 6, Kathy Sierra e Bert Bates


OBRIGADO

48

PROF. EMILIO PARMEGIANI

DOWNLOAD DO MATERIAL


tópicos especiais de programação orientada a objetos · java tópicos especiais ... 8...

Documents