Especialização em web com interfaces ricas. Padrões de Projeto - Estruturais

Transcrição

1 Especialização em web com interfaces ricas Padrões de Projeto - Estruturais Prof. Fabrízzio Alphonsus A. M. N. Soares fabrizzio@inf.ufg.br professor.fabrizzio@gmail.com Instituto de Informática Universidade Federal de Goiás Aula 8 25 de maio de 2012 Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 1/102

2 Padrões de Projeto - Estruturais I Padrões de projeto estruturais são padrões que lidam com as estruturas do projeto, facilitando a comunicação entre suas entidades. Por enquanto, esse conceito permanecerá abstrato, mas de acordo com os padrões deste tipo, entenderemos melhor. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 2/102

3 Padrões de Projeto - Estruturais II Em resumo, estes padrões, em outras palavras cuidam da estrutura de seu projeto. Por outro lado padrões estruturais devem ser aplicados em classes responsáveis pela estrutura dos domínios, fazendo uma analogia com a engenharia civil, eles seriam responsáveis por definir o alicerce da construção bem como a estrutura para sustentá-la. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 3/102

4 Padrões de Projeto - Estruturais III Lista de padrões estruturais Adapter Bridge Composite Decorator Façade Flyweight Proxy Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 4/102

5 Padrão Adapter I Adapter, também conhecido como Wrapper, é um padrão de projeto de software (do inglês design pattern). Este padrão é utilizado para adaptar a interface de uma classe. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 5/102

6 Padrão Adapter II O Adapter permite que classes com interfaces incompatíveis possam interagir. Adapter permite que um objeto cliente utilize serviços de outros objetos com interfaces diferentes por meio de uma interface única. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 6/102

7 Padrão Adapter III O principal objetivo do Adapter é facilitar a conversão da interface de uma classe para outra interface mais interessante para o cliente, fazendo com que várias classes possam trabalhar em conjunto independentemente das interfaces originais. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 7/102

8 Padrão Adapter IV Às vezes é preciso modificar uma classe que não pode ser alterada adequadamente devido à falta do código fonte (alguma biblioteca comercial de classes), ou por alguma outra razão. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 8/102

9 Padrão Adapter V O Adapter é uma das formas de modificar classes nestas circunstâncias, sendo classificado com a de finalidade estrutural e abrange tanto escopo de classe quanto de objeto. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 9/102

10 Motivação I Uma classe já existente e sua interface não combinam com a esperada pelo cliente; Se quer criar uma classe reutilizável que coopera com classes não relacionadas ou não previstas, isto é, classes que não necessariamente tenham interfaces compatíveis; Se necessita usar várias subclasses existentes, mas é impraticável adaptar suas interfaces fazendo um Subclassing de cada uma. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 10/102

11 Aplicabilidade I Desejar usar uma classe existente e sua interface não corresponde ao que você precisa; Desejar criar uma classe reutilizável que coopera com classes imprevistas ou não relacionáveis, isto é, classes que não tem necessariamente interfaces compatíveis. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 11/102

12 Estrutura I Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 12/102

13 Estrutura II Participantes Cliente Colabora entre os objetos conforme a interface Alvo. Alvo Define a interface de domínio específico que o Cliente utiliza. Adaptador Adapta a ClasseExistente para ser utilizada pela classe Alvo. ClasseExistente Define uma interface pré-existente que necessita ser adaptada. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 13/102

14 Vantagens Adapta o Adaptador para o Alvo através de uma classe concreta. Como consequência, uma classe adaptada não funcionará para adaptar uma classe e suas subclasses. Deixa o Adaptador sobrepor algum comportamento do adaptado, desde que o Adaptador seja uma subclasse do adaptado. Introduz um único objeto e nenhum ponteiro adicional é necessário para chegar ao adaptado Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 14/102

15 Exemplo Usou-se como exemplo (adaptado [Software Design Patterns, 2005]), ilustrado na Figura 2, uma implementação que demonstra o uso de um banco de dados químico legado. Objetos da classe CompostoQuimico acessam o banco de dados através de uma interface que utiliza o Padrão Adapter. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 15/102

16 Padrão Bridge I Bridge é um padrão de projeto de software, ou design pattern em inglês, utilizado quando é desejável que uma interface (abstração) possa variar independentemente das suas implementações. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 16/102

17 Padrão Bridge II Imagine um sistema gráfico de janelas que deve ser portável para diversas plataformas. Neste sistema são encontrados diversos tipos de janelas, como ícones, diálogos, etc. Estas janelas formam uma hierarquia que contém uma abstração das janelas (classe base). Normalmente, a portabilidade seria obtida criando-se especializações dos tipos de janelas para cada uma das plataformas suportadas. O problema com essa solução reside na complexidade da hierarquia gerada e na dependência de plataforma que existirá nos clientes do sistema. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 17/102

18 Padrão Bridge III Através do padrão Bridge, a hierarquia que define os tipos de janelas é separada da hierarquia que contém a implementação. Desta forma todas as operações de Janela são abstratas e suas implementações são escondidas dos clientes. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 18/102

19 Propósito Desacopla uma abstração de sua implementação de maneira que ambas possam variar independentemente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 19/102

20 Motivação O que motiva a utilização do padrão Bridge é a necessidade de um driver, permitindo implementações específicas para tratar objetos em diferentes meios persistentes. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 20/102

21 Aplicabilidade Use o Padrão de Projeto Bridge quando: Quando for necessário evitar uma ligação permanente entre a interface e a implementação. Quando alterações na implementação não puderem afetar clientes. Quando implementações são compartilhadas entre objetos desconhecidos do cliente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 21/102

22 Estrutura I Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 22/102

23 Estrutura II Participantes Abstração Define a interface de abstração. Mantém uma referência a um objeto do tipo Implementador. AbstracãoRefinada Estende a interface definida por Abstração. Implementador Define a interface para classes de implementação. Esta não tem a obrigação de corresponder exatamente à interface de abstração. De fato, as duas interfaces podem ser bastante diferentes. Tipicamente, a interface de implementação fornece apenas operações primitivas, cabendo à abstração a responsabilidade de definir operações de alto nível baseadas nestas primitivas. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 23/102

24 Estrutura III ImplementadorConcretoA e implementadorcomcretob Implementação concreta da interface definida por Implementador. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 24/102

25 Vantagens I Detalhes de implementação totalmente inacessíveis aos clientes. Eliminação de dependências em tempo de compilação das implementações. Implementação de abstração pode ser configurada em tempo de execução. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 25/102

26 Implementação I A implementação (adaptado [Software Design Patterns, 2005]) do Padrão Bridge ilustra a Ponte entre a classe abstrata Obeto- Negocios a ClienteDadosObjeto através de interface DadosObjeto. A interface DadosObjeto não é igual a ObjetoNegocios, já que não existe necessária dependência entre elas. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 26/102

27 Implementação II Este exemplo demonstra desacoplamento de uma abstração de ObjetoNegocio da implementação em DadosObjeto. As implementações de DadosObjeto podem evoluir dinamicamente sem propagar mudanças a nenhum dos objetos cliente, isso pode ser verificado na figura 2. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 27/102

28 Implementação III Na classe ClienteDadosObjeto encontra-se a implementação que a classe cliente espera através da DadosObjeto, neste caso, ela contém algumas pessoas cadastradas, ela pode adicionar novas pessoas em determinado grupo ou mostrá-las. Para interagir entre os cadastros utiliza-se o Padrão Iterator, que será detalhado nos próximos Padrões. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 28/102

29 Implementação IV Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 29/102

30 Padrão composite I Composite é um padrão de projeto de software utilizado para representar um objeto que é constituído pela composição de objetos similares a ele. Neste padrão, o objeto composto possui um conjunto de outros objetos que estão na mesma hierarquia de classes a que ele pertence. O padrão composite é normalmente utilizado para representar listas recorrentes - ou recursivas - de elementos. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 30/102

31 Padrão composite II Além disso, esta forma de representar elementos compostos em uma hierarquia de classes permite que os elementos contidos em um objeto composto sejam tratados como se fossem um único objeto. Desta forma, todos os métodos comuns às classes que representam objetos atômicos da hierarquia poderão ser aplicáveis também ao conjunto de objetos agrupados no objeto composto. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 31/102

32 Aplicação I Utilizado sempre que é necessário representar elementos que são compostos por outros elementos similares. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 32/102

33 Exemplo I Por exemplo, em interfaces gráficas um elemento gráfico pode ser constituído pela composição de vários outros elementos gráficos. Uma janela pode conter um ou mais ícones, uma caixa de texto e vários outros elementos gráficos - até mesmo outra janela. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 33/102

34 Exemplo II Considerando que uma determinada hierarquia de classes indicasse ElementoGráfico como a super-classe comum a todas classes que representassem os elementos gráficos atômicos, a classe Janela seria representada como uma classe que contém zero (0) ou mais elementos gráficos. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 34/102

35 Motivação I Aplicações gráficas como editores de desenho e sistemas de captura de esquema deixam os usuários construírem diagramas complexos a partir de Componentes simples. O usuário pode agrupar Componentes para formar Componentes maiores, que, por sua vez, podem ser agrupados para formar Componentes maiores ainda. O Padrão Composite descreve como usar composição recursiva, de modo que os clientes não tenham que fazer distinção entre componentes simples e composições. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 35/102

36 Motivação II Use o Padrão de Projeto Bridge quando: Quiser representar hierarquias parte-todo de objetos; Deseja que os clientes sejam capazes de ignorar as diferenças entre composição de objetos e objetos individuais. Clientes tratarão todos os objetos uniformemente na estrutura Composite. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 36/102

37 Estrutura I Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 37/102

38 Estrutura II Componente Declara a interface para objetos na composição; Implementa comportamento default para interface comum a todas as classes, como apropriado; Declara uma interface para acessar ou gerenciar seus Componentes filhos; Folha Representa objetos folhas na composição. Uma folha não tem filhos; Define comportamento para objetos primitivos na composição. Composição Define comportamento para Componentes que têm filhos; Armazena Componentes filhos; Implementa operações relacionadas com filhos na interface do Componente. Cliente Manipula objetos na composição através da interface Componente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 38/102

39 Consequencias I Vantagens Define a consistência das hierarquias de classes de objetos primitivos e objetos composição. Clientes podem tratar estruturas compostas e objetos individuais uniformemente. Clientes normalmente não sabem (e não deveriam se preocupar) se eles estão tratando com uma folha ou uma composição; Torna mais fácil adicionar novos tipos de Componentes. Novas composições ou subclasses. Folhas trabalham automaticamente com estruturas existentes e código do cliente. Clientes não têm que ser mudados para novas classes de Componentes. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 39/102

40 Consequencias II Desvantagem Quando uma composição tem apenas alguns Componentes, você terá de usar uma checagem em tempo de execução para isto. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 40/102

41 Exemplo I Este exemplo (adaptado [Software Design Patterns, 2005]) do padrão Composite representa uma simulação de sua funcionalidade propriamente dita, ele foi retirado e adaptado do site. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 41/102

42 Exemplo II É apresentado através na classe Tela dois botões para mostrar todas as folhas e componentes e outro simplesmente para limpar. Também se utiliza o padrão para construir uma estrutura de árvore gráfica composta de nós primitivos (estes nós podem ser substituídos por linhas, círculos, etc) e nós compostos (grupos de elementos que formam elementos mais complexos). Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 42/102

43 Exemplo III Assim sendo verifica-se que a classe Folha representa os nós primitivos, ou seja, elas não possuem nenhuma classe folha. A classe Componente apenas possui os atributos e métodos comuns a todos seus filhos (ou folhas). Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 43/102

44 Exemplo IV Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 44/102

45 Padrão Decorator I Atribui responsabilidade adicionais a um objeto dinamicamente. O Decorator fornece uma alternativa flexível a subclasses para a extensão da funcionalidade. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 45/102

46 Propósito I Agregar responsabilidades adicionais a um objeto dinamicamente. Classes decoradoras oferecem uma alternativa flexível ao uso de herança para estender uma funcionalidade [Silva, 2005]. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 46/102

47 Motivação I Adicionar responsabilidades a um objeto, mas não à sua classe. Acontece, por exemplo, com criação de interfaces gráficas, quando se deseja acrescentar uma borda a um componente qualquer ou uma barra de rolagem a uma área de texto. Uma abordagem mais flexível é inserir o componente em outro objeto que adiciona a borda, um Decorator [Silva, 2005]. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 47/102

48 Aplicabilidade I Utilizado para adicionar responsabilidades a objetos individuais de forma dinâmica e transparente, isto é, sem afetar outros objetos, da mesma forma, quando se quer retirar responsabilidades. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 48/102

49 Aplicabilidade II Quando a utilização de heranças para a implementação do mesmo afetará a flexibilidade do sistema. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 49/102

50 Aplicabilidade III Um caso de aplicação do Decorator é quando existem muitas variações de um objeto. Imagine por exemplo uma classe Janela com uma subclasse JanelaComBorda. Se houver a necessidade também de janelas com rolagem, tem-se ainda JanelaComRolagem e JanelaComBordaERolagem [Faerman, 2005], além de outras possíveis combinações, já que poderia haver menus, botões ou barra de status. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 50/102

51 Aplicabilidade IV Usando o Decorator, tem-se um número muito menor de subclasses: Janela, DecoratorJanela, DecoratorJanelaBorda, DecoratorJanelaRolagem, DecoratorJanelaMenu, e assim por diante [Faerman, 2005]. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 51/102

52 Estrutura I Esse padrão providencia que cada objeto Decorator contenha outro objeto Decorator. Nesse aspecto, um decorator é como um pequeno composite cujos elementos possuem cada qual um filho único. Diferentemente do padrão Composite, cujo propósito é compor objetos agregados, o propósito do Decorator é compor comportamentos. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 52/102

53 Estrutura II Estruturalmente, o padrão Decorator dispõe as classes em um hierarquia e distribui operações ao longo dela. Cada classe dessa hierarquia tipicamente tem um construtor que precisa de outra instância de uma classe dela. As classes Decorator tipicamente implementam suas operações por meio da dependência do objeto decorador que recebem em seus construtores [Metsker, 2004]. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 53/102

54 Estrutura III Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 54/102

55 Estrutura IV Participantes Componente define a interface para objetos que podem ter responsabilidades acrescentadas a eles dinamicamente. ComponenteConcreto define um objeto para o qual responsabilidades adicionais podem ser atribuídas Decorator mantém uma referência para um objeto Componente. Define uma interface que segue a interface de Componente. DecoratorConcretoA e DecoratorConcretoB acrescenta responsabilidades ao componente Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 55/102

56 Vantagens I Fornece uma flexibilidade maior do que a herança estática. Evita a necessidade de colocar classes sobrecarregadas de recursos em uma posição mais alta da hierarquia. Simplifica a codificação permitindo que você desenvolva uma série de classes com funcionalidades específicas, em vez de codificar todo o comportamento no objeto. Aprimora a extensibilidade do objeto, pois as alterações são feitas codificando novas classes. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 56/102

57 Exemplo de implementação I Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 57/102

58 Exemplo de implementação II O exemplo ilustrado na Figura, visa gerar janelas com características que podem variar de uma janela para outra. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 58/102

59 Exemplo de implementação III Por exemplo, o cliente pode decidir entre construir uma janela com barra de menus ou não. Desta forma consegue-se aumentar o número de possibilidades de janelas diferentes apresentadas com um pequeno número de classes. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 59/102

60 Exemplo de implementação IV Neste exemplo, a interface Janela recebe o papel de ser o Componente da estrutura apresentada anteriormente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 60/102

61 Exemplo de implementação V Por sua vez, JanelaComum interpreta o ComponenteConcreto, ou seja, é ele que receberá as modificações no decorrer da execução da aplicação. Como o próprio nome diz, o Decorator assume a finalidade do Decorator da estrutura padrão. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 61/102

62 Exemplo de implementação VI JanelaMenuBar, JanelaBorda, JanelaBarraStatus e JanelaBarraFerramenta herdam de Decorator, ou seja, são os n decoradores concretos. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 62/102

63 Padrão Façade I Em padrões de projeto de software, um façade (fachada em francês) é um objeto que disponibiliza uma interface simplificada para uma das funcionalidades de uma API, por exemplo. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 63/102

64 Padrão Façade II Um façade pode: tornar uma biblioteca de software mais fácil de entender e usar; tornar o código que utiliza esta biblioteca mais fácil de entender; reduzir as dependências em relação às características internas de uma biblioteca, trazendo flexibilidade no desenvolvimento do sistema; envolver uma interface mal desenhada, com uma interface melhor definida. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 64/102

65 Padrão Façade III Os façades são muito comuns em projeto orientados a objeto. Por exemplo, a biblioteca padrão da linguagem Java contém dúzias de classes para processamento do arquivo fonte de um caractere, geração do seu desenho geométrico e dos pixels que formam este caractere. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 65/102

66 Padrão Façade IV Entretanto, a maioria dos programadores Java não se preocupam com esses detalhes, pois a biblioteca contém as classes do tipo façade (Font e Graphics) que oferecem métodos simples para as operações relacionadas com fontes. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 66/102

67 Propósito I Oferecer uma interface única para um conjunto de interfaces de um subsistema. Definir uma interface de nível mais elevado que torna o subsistema mais fácil de usar [Silva, 2005]. Reduzir a complexidade do relacionamento entre uma classe relativa ao cliente e as demais classes utilitárias [Junior, 2004]. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 67/102

68 Motivação I Uma grande vantagem da programação orientada a objetos é que ela ajuda a evitar que as aplicações se tornem programas monolíticos, com pedaços incorrigivelmente entrelaçados. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 68/102

69 Motivação II No entanto, a aplicabilidade variada das classes em um subsistema orientado a objetos pode oferecer uma variedade expressiva de opções [Metsker, 2004]. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 69/102

70 Motivação III Existem circunstâncias onde é necessário utilizar diversas classes diferentes para que uma tarefa possa ser completada, caracterizando uma situação onde uma classe cliente necessita utilizar objetos de um conjunto específico de classes utilitárias que, em conjunto, compõem um subsistema particular ou que representam o acesso a diversos subsistemas distintos. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 70/102

71 Motivação IV Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 71/102

72 Aplicabilidade I Criação de interfaces mais simples para um ou mais subsistemas complexos. Redução de dependência entre o cliente e as classes existentes nos subsistemas, ocasionando a redução da coesão do sistema Criação de sistemas em camadas. Este padrão provê o ponto de entrada para cada camada (nível) do subsistema. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 72/102

73 Estrutura I A estrutura deste padrão é bastante simples. A classe que constituirá o Facade deverá oferecer um conjunto de operações que sejam suficientes para que seus clientes possam utilizar adequadamente o subsistema, embora sem conhecer as interfaces de seus componentes. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 73/102

74 Estrutura II O Facade é um padrão que pode apresentar infinidades de formas de representá-lo. O que importa para este padrão é que o Cliente apenas acesse objetos da classe Facade, esperando algum resultado vindo dela. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 74/102

75 Estrutura III A classe Facade é que terá a responsabilidade de entrar em contato com as diversas instâncias dentro deste sistema, efetuar possíveis cálculos vindos de classes abaixo dela e retornar as respostas que o cliente pediu. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 75/102

76 Estrutura IV Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 76/102

77 Estrutura V Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 77/102

78 Vantagens I Protege os clientes da complexidade dos componentes do subsistema; Promove acoplamento fraco entre o subsistema e seus clientes; Reduz dependências de compilação, possivelmente complexas ou circulares; Facilita a portabilidade do sistema [Junior, 2004]; Reduz a união entre subsistemas desde que cada subsistema utilize seu próprio padrão Facade e outras partes do sistema utilizem o padrão Facade para comunicar-se com o subsistema [Allen e Bambara, 2003]; Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 78/102

79 Vantagens II Não evita que aplicações possam acessar diretamente as subclasses do sistema, se assim o desejarem [Junior, 2004]; Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 79/102

80 Implementação I Implementar um Facade demanda definir um conjunto de operações reduzidas que permita ocultar a complexidade inerente à utilização de várias classes de um subsistema (adaptado [Software Design Patterns, 2005]). Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 80/102

81 Implementação II Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 81/102

82 Implementação III Neste exemplo, o cliente necessita consultar várias entidades a fim de saber se têm condições de receber um empréstimo. Para isso, normalmente, o cliente teria que conhecer toda a complexidade envolvida com as regras de concessão de empréstimos e aprende-las, no entanto, nada melhor do que deixar isso a cargo de quem já está no sistema, no caso o Facade, que irá se preocupar em colher dados das diferentes classes que podem decidir sobre a possibilidade do empréstimo e retornará esta informação pronta para o cliente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 82/102

83 Implementação IV FacadeApp é o cliente que busca informações que podem vir de vários de subsistemas, Facade é a classe responsável por acessar os subsistemas e trazer respostas de forma transparente a quem esteja acessando o Facade. Banco, Emprestimo, Crédito e Consumidor são classes pertencentes aos subsistemas. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 83/102

84 O padrão Flyweight I Flyweight é um padrão de projeto de software apropriado quando vários objetos devem ser manipulados, e esses não suportam dados adicionais. No padrão flyweight não existem ponteiros para os métodos do dado, pois isto consome muita memória. Em contrapartida são chamadas sub-rotinas diretamente para acessar o dado. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 84/102

85 Propósito I Utilizar compartilhamento para suportar eficientemente um grande número de objetos com estado reduzido Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 85/102

86 Motivação I Em um editor de textos certas vantagens são obtidas as representar cada caractere como objeto Entretanto, seria necessário a instanciação de um número consideravelmente alto de objetos, com consumo excessivo de memória e overhead de execução Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 86/102

87 Motivação II Um flyweight é um objeto compartilhado que pode ser utilizado simultaneamente em múltiplos contextos Atua como um objeto independente em cada contexto, de modo que os clientes não são cientes do compartilhamento O conceito chave é a distinção entre estado intrínseco e estado extrínseco: O estado intrínseco é armazenado no flyweight e consiste de informações independentes do contexto e, portanto, compartilháveis O estado extrínseco depende de e varia com o contexto e, portanto, não pode ser compartilhado. Os clientes são responsáveis por passar o estado extrínseco para o flyweight, quando necessário Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 87/102

88 Problema exemplo I Desenvolver um editor de texto onde cada caractere é representado por um objeto: Granularidade muito pequena; Não haverá recursos (memória) suficiente para textos grandes. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 88/102

89 Solução I Monta-se um pool de objetos compartilhados; Cada caractere tem um objeto. Com 100 objetos (tabela ASCII) poderíamos montar textos de qualquer tamanho. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 89/102

90 Estrutura I Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 90/102

91 Usar este padrão quando? I Todas as condições forem verdadeiras: A aplicação usa um grande número de objetos; O custo de armazenamento é alto por causa desta quantidade; O estado dos objetos pode ser externalizado; Objetos podem ser compartilhados assim que seu estado é externalizado; A aplicação não depende da identidade. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Estruturais 91/102