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

Apresentação em tema: "April 05 Prof. Ismael H. F. Santos - 1 Módulo III Padrões GOF-II: Iterator e Composite Professores Eduardo Bezerra –"— Transcrição da apresentação:

1 April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 1 Módulo III Padrões GOF-II: Iterator e Composite Professores Eduardo Bezerra – edubezerra@gmail.comedubezerra@gmail.com Ismael H F Santos – ismael@tecgraf.puc-rio.brismael@tecgraf.puc-rio.br

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

3 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

4 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. http://www.mindview.net/Books/TIJ/http://www.mindview.net/Books/TIJ/

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

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

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

8 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

9 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.

10 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().

11 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(); }

12 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(); }

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

14 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.

15 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.

16 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.

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

18 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.

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

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

21 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

22 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

23 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.

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

25 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

26 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:

27 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...

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

29 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.

30 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.

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

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

33 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.

34 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

35 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

36 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.