April 05 Prof. Ismael H. F. Santos - 1 Módulo III Padrões GOF-II: Iterator e Composite Professores Eduardo Bezerra –

Slides:



Advertisements
Apresentações semelhantes
Carlos Roberto Marques Junior
Advertisements

Padrão de Projeto Iterator
Projeto de Sistemas de Software Trabalho de Padrões de Projeto
Projeto de Sistemas de Software
Padrão de Projeto Iterator
Padrão Abstract Factory
April 05 Prof. Ismael H. F. Santos - 1 Programação Banco de Dados em Java Prof. Ismael H F Santos.
1 Introdução aos padrões de projeto (GoF) Conceitos preliminares –Mecanismos de herança –Princípio de Substituição de Liskov –Acoplamento concreto x Acoplamento.
Módulo III Padrões GOF: Composite
April 05 Prof. Ismael H. F. Santos - 1 Programação Web com Java Prof. Ismael H F Santos.
Módulo III Padrões GOF-VI: MVC
April 05 Prof. Ismael H. F. Santos - 1 Frameworks e Padrões de SW Prof. Ismael H F Santos.
April 05 Prof. Ismael H. F. Santos - 1 Programação OO em Java Básico Prof. Ismael H F Santos.
April 05 Prof. Ismael H. F. Santos - 1 Módulo VI – J ava Standard Template Library (JSTL) Prof. Ismael H F Santos.
Módulo III Padrões GOF: Command
April 05 Prof. Ismael H. F. Santos - 1 Modulo II – Tópicos em Java – Relatórios Prof. Ismael H F Santos.
April 05 Prof. Ismael H. F. Santos - 1 Módulo III Padrões GOF:FactoryMethod Professores Eduardo Bezerra –
Abstract Factory Intenção: fornecer uma interface comum para a criação de famílias de objetos relacionados ou dependentes, sem especificar suas classes.
Padrões GoF - Composite
Eduardo Bezerra Padrões GoF Eduardo Bezerra
Padrões GoF – Factory Method
Modulo I Padrões GRASP Professores
April 05 Prof. Ismael H. F. Santos - 1 Módulo II XML Processing: XSLT, SAX e DOM Prof. Ismael H F Santos.
Professor: Hyggo Almeida
Fundamentos da Engenharia de Software
Nazareno Andrade (baseado no material de Hyggo Almeida)
Padrões de projeto detalhados Factory Method, Abstract Factory
Módulo III Padrões GOF Professores
Design Patterns Bridge
Estudo de Caso: um editor de documentos
Programação Orientada à Objetos
SISTEMAS DISTRIBUIDOS Aula 4
Interfaces e classes abstratas. Conceitos de Orientação a Objeto.
Introdução Eduardo Figueiredo 04 de Março de 2010 POOAula 01 ou
April 05 Prof. Ismael H. F. Santos - 1 Módulo I Princípios e Padrões de Projeto de SW em Java Professores Eduardo Bezerra –
Padrão de Projeto Iterator Projeto de Sistemas de Software Thiago Pinheiro de Araújo.
April 05 Prof. Ismael H. F. Santos - 1 Módulo III Padrões GOF: Singleton, Professores Eduardo Bezerra –
Padrões de Projeto Abstract Factory.
Factory.
April 05 Prof. Ismael H. F. Santos - 1 Modulo I Princípios e Padrões de Projeto de SW em Java Professores Eduardo Bezerra –
April 05 Prof. Ismael H. F. Santos - 1 Módulo III Padrões GOF: Iterator Professores Eduardo Bezerra –
Abstract Factory Pattern Algumas aplicações precisam criar objetos de classes que podem mudar ex: elementos de um sistema GUI. –Diferentes padrões precisam.
April 05 Prof. Ismael H. F. Santos - 1 Módulo III Padrões GOF: Memento Professores Eduardo Bezerra –
April 05 Prof. Ismael H. F. Santos - 1 Modulo IV Padrões Core J2EE Professores Eduardo Bezerra –
April 05 Prof. Ismael H. F. Santos - 1 Módulo III Padrões GOF: AbstractMethod Professores Eduardo Bezerra –
April 05 Prof. Ismael H. F. Santos - 1 Módulo III Padrões GOF: Strategy Professores Eduardo Bezerra –
Design Patterns A adoção dos padrões terá um efeito profundo e duradouro sobre a forma de escrevermos programas Ward Cunningham e Ralph Johnson.
April 05 Prof. Ismael H. F. Santos - 1 Módulo III Padrões GOF: Observer Professores Eduardo Bezerra –
April 05 Prof. Ismael H. F. Santos - 1 Módulo V- Modelo MVC-Web Prof. Ismael H F Santos.
April 05 Prof. Ismael H. F. Santos - 1 Módulo III Padrões GOF: State Professores Eduardo Bezerra –
1 Padrão: Iterador (Iterator) Tipo - “Object behavioral” Objetivo - acessar um agregado sem expor a representação Outros nomes - Cursor.
1 Padrões: Composite (p. 163) Objetivo: compor objetos em estruturas de árvores para representar relações de parte/todo. “Composite” permite tratar objetos.
Padrões de projeto M.Sc. Sílvio Bacalá Jr..
April 05 Prof. Ismael H. F. Santos - 1 Modulo II – Tópicos em Java - Ant Prof. Ismael H F Santos.
April 05 Prof. Ismael H. F. Santos - 1 Modulo II – Tópicos em Java – Generics Prof. Ismael H F Santos.
Padrão Composite Definição
April 05 Prof. Ismael H. F. Santos - 1 Modulo V Frameworks Professores Eduardo Bezerra –
Jobson Ronan Padrões GoF Jobson Ronan
TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ANÁLISE E PROJETO DE SISTEMAS Semana /08/2012 Professor Leomir J. Borba-
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
Padrões de Projetos Orientados a Objetos I Wolley W. Silva.
PADROES DE PROJETO PROF. OSIEL MARLON. PADRÕES DE PROJETO INTRODUÇÃO Padrões de projeto têm emergido como uma das mais promissoras abordagens para a melhoria.
Padrões de Projeto. O que são?  Soluções provenientes de diversos projetos e utilizados por diversos programadores;  Documentados em catálogos como.
1 Especificação de Sistemas de Software e a UML. 2 Modelagem de sistema A modelagem de sistema auxilia o analista a entender a funcionalidade do sistema.
TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ANÁLISE E PROJETO DE SISTEMAS Aula /08/2012 Professor Leomir J. Borba-
CIn-UFPE1 Projeto de Gerenciamento de Dados. CIn-UFPE2 Objetivos n Definir o que significa gerenciamento de dados do sistema; n Entender abordagens diferentes.
Engenharia de Software Orientada a Objetos Professor: Guilherme Timóteo Aula 3: – Modelagem de Classes (parte 2)
Padrões de Projeto de Criação Padrões de Projeto Orientados a Objetos Prof a. Danielle Martin Universidade de Mogi das Cruzes.
1 Introdução aos Padrões de Projetos (na prática) Créditos: Lúbia Vinhas Hazel Carvalho Crato Adaptações: Prof. Nécio de Lima Veras.
Transcrição da apresentação:

April 05 Prof. Ismael H. F. Santos - 1 Módulo III Padrões GOF-II: Iterator e Composite Professores Eduardo Bezerra – Ismael H F Santos –

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 2 Ementa Padrões – Parte II Iterator Composite Bridge

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 3 Craig Larman, Utilizando UML e Padrões, Ed Bookman Eric Gamma, et ali, Padrões de Projeto, Ed Bookman Martin Fowler, Analysis Patterns - Reusable Object Models, Addison-Wesley,1997 Martin Fowler, Refatoração - Aperfeiçoando o projeto de código existente, Ed Bookman Bibliografia

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 4 Livros Core Java 2, Cay S. Horstmann, Gary Cornell Volume 1 (Fundamentos) Volume 2 (Características Avançadas) Java: Como Programar, Deitel & Deitel Thinking in Patterns with JAVA, Bruce Eckel Gratuito.

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 5 Padrões Parte II POO-Java

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 6 Iterator POO-Java

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 7 Iterator Toda cole ç ão possui uma representa ç ão interna para o armazenamento e organiza ç ão de seus elementos. Por outro lado, essa coleção deve permitir que seus elementos sejam acessados sem que sua estrutura interna seja exposta. De uma maneira geral, pode-se desejar que estes elementos sejam percorridos de várias maneira, sem no entanto ter que modificar a interface da coleção em função do tipo de varredura desejado. de frente para trás, vice-versa, ou mesmo em ordem aleatória.

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 8 Iterator O padrão Iterator permite descrever uma forma de percorrer os elementos de uma cole ç ão sem violar o encapsulamento dessa cole ç ão. Inten ç ão: iterar sobre (percorrer seq ü encialmente) uma cole ç ão de objetos sem expor sua representa ç ão. Obedecer o princ í pio do encapsulamento

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 9 Iterator Solu ç ão: um objeto intermedi á rio (iterator) é usado entre o cliente e a cole ç ão de objetos. Este objeto conhece a estrutura interna da cole ç ão a ser percorrida, e apresenta uma interface para percorrer tal estrutura. Esta interface é independente dessa estrutura interna. Os clientes que desejam percorrer a cole ç ão utilizam a interface do objeto intermedi á rio, em vez de se comunicarem diretamente com a cole ç ão de objetos.

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 10 Iterator Requisitos de um iterador Um modo de localizar um elemento espec í fico da cole ç ão, tal como o primeiro elemento. Um modo de obter acesso ao elemento atual. Um modo de obter o pr ó ximo elemento. Um modo de indicar que não h á mais elementos a percorrer. Exemplo em Java As classes List, Set e Sorted são subclasses de Collection, e herdam um m é todo iterator() que retorna um objeto iterador. O objeto Iterator possui m é todos hasNext() e next().

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 11 Iterator (exemplo) // ICollection.java // interface para obtenção de Iterator para coleções public interface ICollection { // obtenção de um Iterator public IIterator getIterator(); // determina existência de um elemento public boolean has(Object object); // adição de um elemento public boolean add(Object object); // remoção de um elemento public boolean remove(Object object); // remoção de todos os elementos public void removeAll(); }

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 12 Iterator (exemplo) // IIterator.java public interface IIterator { // verifica a existência de um próximo elemento public boolean hasNext(); // retorna o próximo elemento public Object next(); }

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 13 Iterator (estrutura)

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 14 Iterator (participantes) Iterator Define um interface para o acesso e varredura; ConcreteIterator Implementa a interface do Iterator; Mantém referência (cursor) ao objeto que está sendo percorrido, podendo calcular qual o elemento seguinte. Aggregate Define um interface para a criação do objeto Iterator; ConcreteAggregate Implementa o método da interface que retorna uma instância do ConcreteIterator.

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 15 Iterator (aplicabilidade) O uso do padrão Iterator se aplica quando se quer: acessar o conteúdo de objeto agregados sem expor sua representação interna; dar suporte a mais de uma maneira de percorrer a lista; prover interface única para percorrer estruturas agregadas diferentes.

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 16 Iterator (conseqüências) Mant é m separadas a representa ç ão interna e a responsabilidade de navega ç ão pelas partes. O iterador conhece a estrutura interna das partes, mas os clientes do iterador não conhecem. Move da cole ç ão de objetos para o objeto iterator a responsabilidade de acesso e varredura da cole ç ão. A coleção ainda é responsável por criar seus próprios iteradores e o faz através do padrão “Factory Method”. H á a possibilidade de utilizar mais de um iterador simultaneamente. D á suporte a m ú ltiplas maneiras de percorrer a cole ç ão e, se necess á rio, essas varreduras podem ocorrer ao mesmo tempo.

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 17 Composite POO-Java

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 18 Composite São comuns as situações onde temos que lidar com uma coleção de elementos estruturada hierarquicamente (em vez coleções “lineares”). Problema: como criar objetos utilizando partes de tal forma que tanto o objeto todo quanto os objetos parte forneçam a mesma interface para os seus clientes? Composições podem cumprir com este requisito e ainda permitir: o tratamento da composição como um todo; ignorar as diferenças entre composições e elementos individuais; a adição transparente de novos tipos a hierarquia; a simplificação do cliente.

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 19 Composite (estrutura)

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 20 Composite (exemplo) Expressões lógicas (booleanas)

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 21 Composite (conseqüências) Objetos complexos podem ser compostos de objetos mais simples recursivamente. Permite forma assim uma hierarquia de objetos O cliente pode tratar objetos “parte” e objetos “todo” da mesma forma. Isso resulta na simplificação deste cliente. Os clientes normalmente não sabem (e nem devem se preocupar) se eles estão tratando um componente individual ou composto. Facilita a adição de novos componentes: o cliente não tem que mudar com a adição de novos objetos Sejam eles simples ou compostos

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 22 Composite (conseqüências) O projeto pode ficar geral demais, o que torna mais difícil restringir os possíveis componentes de um objeto composto. Por exemplo, em uma hierarquia que contenha documentos e suas partes (seções, parágrafos, etc.), podemos compor seções com documentos, etc. o que não faz sentido

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 23 Composite (aplicabilidade) Quando é necessário representar hierarquias do tipo todo-parte. Quando é necessário tratar todo e respectivas partes de forma indistinta.

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 24 Bridge POO-Java

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 25 Bridge Inten ç ão: desacoplar uma abstra ç ão de sua implementa ç ão de tal forma que a implementa ç ão possa ser facilmente trocada. Solu ç ão: encapsular os detalhes de implementa ç ão em um objeto que é um componente da abstra ç ão

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 26 Bridge Considere a constru ç ão de um m ó dulo para desenhar figuras. Considere que h á duas classes externas de desenho a serem utilizadas: DP1 e DP2 Primeira versão: “ somente retângulos devem ser desenhados ”. Solu ç ão:

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 27 Bridge Suponha agora, o seguintes novos requisitos: “ As classes externas agora desenham c í rculos. Portanto, nosso m ó dulo de desenho deve tamb é m ter a possibilidade de desenhar c í rculos ”. “ Al é m disso, o cliente do nosso m ó dulo de desenho não precisa saber a diferen ç a entre um retângulo e um c í rculo. ” Solu ç ão: Criamos uma classe abstrata Shape, e fazemos com que ela seja superclasse tanto de Rectangle quanto de Circle. O cliente agora se comunica com objetos Shape. Sendo assim, temos uma nova solu ç ão, apresentada a seguir...

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 28 Bridge

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 29 Bridge Infelizmente, a solu ç ão da figura anterior introduz alguns problemas: O que acontece se preciso dar suporte a um novo programa de desenho? E se um novo tipo de Figura (Shape) tiver que ser adicionado? O que aconteceria com a complexidade de manuten ç ão neste m ó dulo quando a quantidade de tipos de figura e de m ó dulos externos de desenho chegasse à cada das dezenas? Resposta: explosão de classes.

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 30 Bridge A explosão de classes surge porque, nesta solu ç ão, a abstra ç ão (ou seja, os tipos de Shape) e a implementa ç ão (os programas de desenho) estão fortemente acoplados. i.e., cada tipo de figura (abstra ç ão) deve saber que tipo de m ó dulo externo (implementa ç ão) ele deve utilizar. Precisamos de um modo de separar (desacoplar) as varia ç ões na abstra ç ão das varia ç ões na implementa ç ão, de tal forma que o n ú mero de classes cres ç a somente linearmente. Esta é exatamente a inten ç ão (objetivo) do padrão Bridge.

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 31 Bridge

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 32 Bridge (estrutura)

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 33 Bridge (exemplo) Java Swing possui diversos “ look and feels ”. Objetos JFrame, JButton, etc. possuem um componente interno (peer) que é constru í do para com um look and feel particular. No entanto, clientes (programadores) somente precisam interagir com JFrame, JButton, etc.

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 34 Bridge (exemplo) O método UIManager.setLookAndFeel define a fábrica concreta para “produtos” do Windows. WindowsLookAndFeelDefaultLookAndFeel

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 35 Bridge (exemplo) Exemplo: usando o padrão Bridge para abstrair o driver específico de banco de dados. JDBC Implementation JDBC imp Oracle JDBC Driver MySQL JDBC Driver Postgress JDBC Driver

Julho 06 Prof(s). Eduardo Bezerra & Ismael H. F. Santos 36 Bridge (aplicabilidade) Aplicabilidade O padrão Bridge é ú til quando se tem uma abstra ç ão que tem diferentes implementa ç ões. Este padrão permite que a abstra ç ão e a sua implementa ç ão variem independentemente.