Padres de Projeto 2001 Jaelson Castro Padres de

  • Slides: 123
Download presentation
Padrões de Projeto © 2001 Jaelson Castro Padrões de Projeto 1

Padrões de Projeto © 2001 Jaelson Castro Padrões de Projeto 1

Objetivos n n O que é entendido pelo termo padrão Que tipos de padrões

Objetivos n n O que é entendido pelo termo padrão Que tipos de padrões têm sido identificados no desenvolvimento de software Como aplicar padrões de projeto durante o desenvolvimento de software Os benefícios e dificuldades que podem surgir quando usamos padrões © 2003 Jaelson Castro Padrões de Projeto 2

Padrões n Projetar software OO bom e reusável é difícil. n n Mistura de

Padrões n Projetar software OO bom e reusável é difícil. n n Mistura de específico+ genérico Impossível acertar da primeira vez Projetistas experientes usam soluções com as quais já trabalharam no passado. Padrões de projeto n Sistematicamente n n n © 2003 Jaelson Castro nomes, explicações, e avaliações Padrões de Projeto 3

Genesis n Christopher Alexander, et. al. 1977 “Cada padrão descreve um problema que ocorre

Genesis n Christopher Alexander, et. al. 1977 “Cada padrão descreve um problema que ocorre sempre em nosso ambiente, e então descreve o núcleo de uma solução para o problema, de que maneira você pode usar esta solução um milhão de vezes mais, sem fazê-la do mesmo jeito duas vezes. ” Apropriada para prédios e pontes. Durante a última década, uma “comunidade de padrões” tem sido desenvolvida. n n © 2003 Jaelson Castro Padrões de Projeto 4

Genesis n “Um padrão é a abstração de uma forma concreta que ocorre muitas

Genesis n “Um padrão é a abstração de uma forma concreta que ocorre muitas vezes em contextos não arbitrários específicos. ” Riehle and Zullighoven, 1996 n n “Cada padrão é uma regra de três partes, que expressa uma relação entre um certo contexto, um certo sistema de forças que ocorre repetidamente naquele contexto, e uma certa configuração de software que permite que estas forças resolvaos” Gabriel 1996. “Resolve um problema. É um conceito provado. A solução não é óbvia. Descreve um relacionamento. Os padrões têm um componente humano significativo. ” Coplien 1996. © 2003 Jaelson Castro Padrões de Projeto 5

Características dos Padrões de Software n n Algo comprovado que captura, comunica os conhecimentos

Características dos Padrões de Software n n Algo comprovado que captura, comunica os conhecimentos das melhores práticas. A solução não é óbvia. Descoberto, não inventado. O padrão tem um componente humano importante (ex. qualidades estéticas nos padrões de Alexander) © 2003 Jaelson Castro Padrões de Projeto 6

Anti-Padrões n Anti-padrões é uma maneira de documentar soluções recorrentes de soluções que não

Anti-Padrões n Anti-padrões é uma maneira de documentar soluções recorrentes de soluções que não tiveram sucesso n © 2003 Jaelson Castro Pode também incluir soluções re-trabalhadas que sejam efetivas. Padrões de Projeto 7

Padrões n Padrões de Análise: n n Padrões de Arquitetura: n n Descreve a

Padrões n Padrões de Análise: n n Padrões de Arquitetura: n n Descreve a estrutura e o relacionamento da maioria dos componentes de um sistema de software Padrões de Projeto: n n Descreve grupos de conceitos que representam construções comuns na modelagem do domínio. Estes padrões podem ser aplicáveis em um domínio ou em muitos. Identifica as relações internas entre um grupo de componentes de software e descreve suas responsabilidades, colaborações e relações estruturais. Idiomas n Descreve como implementar aspectos específicos de um sistema de software numa dada linguagem de programação © 2003 Jaelson Castro Padrões de Projeto 8

Frameworks n n Sistemas de software parcialmente completos podem ter como alvo um tipo

Frameworks n n Sistemas de software parcialmente completos podem ter como alvo um tipo específico de aplicação Um sistema de aplicação apropriado para uma organização pode ser desenvolvido a partir de um framework para completar os elementos não concluídos e adicionar elementos específicos da aplicação © 2003 Jaelson Castro Padrões de Projeto 9

Diferenças entre os Padrões de Projeto e Frameworks n n Padrões são mais abstratos

Diferenças entre os Padrões de Projeto e Frameworks n n Padrões são mais abstratos e genéricos que frameworks. Diferente de um framework, um padrão não é diretamente implementado num ambiente de software específico. n n n Um framework pode ser escrito em linguagens de programação e não apenas estudado, mas executado e reusado diretamente. Ao contrário, padrões são implementados cada vez que são usados Padrões são mais primitivos que frameworks. Um framework típico contém vários padrões, mas o inverso nunca é verdade. © 2003 Jaelson Castro Padrões de Projeto 10

Catálogos e Linguagens de Padrões n n Um catálogo de padrões é um grupo

Catálogos e Linguagens de Padrões n n Um catálogo de padrões é um grupo de padrões que estão relacionados de uma certa forma e podem ser usados juntos ou independentemente. Os padrões numa linguagem de padrões estão mais relacionados, e trabalham juntos para solucionar problemas num domínio específico n n um conjunto de padrões que todos trabalham juntos para solucionar um grande problema. Ex: linguagem de padrões para integridade de informações (Cunningham 95) © 2003 Jaelson Castro Padrões de Projeto 11

Princípios Presentes nos Padrões n n n n n Abstração Encapsulamento Proteção de informação

Princípios Presentes nos Padrões n n n n n Abstração Encapsulamento Proteção de informação Modularização Separação de conteúdos Acoplamento e coesão Suficiência, completude e primitividade Separação entre política e implementação Único ponto de referência Dividir para conquistar © 2003 Jaelson Castro Padrões de Projeto 12

Padrões e requisitos nãofuncionais n Padrões podem abordar as características descritas através de requisitos

Padrões e requisitos nãofuncionais n Padrões podem abordar as características descritas através de requisitos não funcionais: n n n Modificabilidade Interoperabilidade Eficiência Confiabilidade Testabilidade Reusabilidade © 2003 Jaelson Castro Padrões de Projeto 13

Template para Documentação de um Padrão Elementos Mínimos: Nome do Padrão: Deve ser facilmente

Template para Documentação de um Padrão Elementos Mínimos: Nome do Padrão: Deve ser facilmente lembrado, reflete o conteúdo do padrão. Problema: Uma descrição do problema que pode ser escrito em forma de pergunta. Contexto: Descreve o contexto do problema. As circunstâncias ou pré-condições sob as quais o problema pode ocorrer. Forças: As restrições ou características que devem ser seguidas pela solução. As forças podem interagir e ter conflitos umas com as outras. Solução: Deve ser direta e precisa. © 2003 Jaelson Castro Padrões de Projeto 14

Template de padrão: Outros Elementos n n n Um exemplo A razão que justifica

Template de padrão: Outros Elementos n n n Um exemplo A razão que justifica a solução escolhida Padrão relacionado Uso conhecido do padrão Lista de outros nomes para o padrão Amostra de código do programa © 2003 Jaelson Castro Padrões de Projeto 15

Problemas com padrões de documentação n n Não há nada como um template perfeito.

Problemas com padrões de documentação n n Não há nada como um template perfeito. Considere n n n © 2003 Jaelson Castro Porque ter um ‘Estilo da Empresa’? Quem usará os padrões documentados? Como eles serão usados? Qual a composição de texto, diagramas e código? Como prevenir erros de uso? Padrões de Projeto 16

Padrões de Projeto n Padrões de Projeto foram introduzidos para a comunidade OO através

Padrões de Projeto n Padrões de Projeto foram introduzidos para a comunidade OO através de n n Gamma E. , et al, Design Patterns, Addison. Wesley, 1994 Eles categorizaram (23) padrões em três tipos: n Criação (5) n Estrutural (7) n Comportamental (11) © 2003 Jaelson Castro Padrões de Projeto 17

Escopo n Classe n n Relacionamentos entre classes e suas subclasses Não precisa executar

Escopo n Classe n n Relacionamentos entre classes e suas subclasses Não precisa executar nenhum código para determinar o uso dos padrões Estático, fixo em tempo de compilação Objeto n n © 2003 Jaelson Castro Confia em ponteiros de objetos. Pode ser alterado em tempo de execução, são mais dinâmicos. Padrões de Projeto 18

Propósito dos Padrões n n n Criação n Relacionado com o processo de criação

Propósito dos Padrões n n n Criação n Relacionado com o processo de criação do objeto Estrutural n Relacionado com os relacionamentos entre classes e objetos n Oferece caminhos efetivos para usar conceitos OO como herança, agregação e composição Comportamental n Relacionado com os caminhos para que objetos e classes distribuam a responsabilidade para realizar a mesma tarefa. © 2003 Jaelson Castro Padrões de Projeto 19

Padrão criação n Abstraem o processo de criação de instâncias (objetos), oferecendo flexibilidade no

Padrão criação n Abstraem o processo de criação de instâncias (objetos), oferecendo flexibilidade no que é criado, por quem, como e quando. © 2003 Jaelson Castro Padrões de Projeto 20

Alguns Exemplos n Padrão criação n n n © 2003 Jaelson Castro Singleton Abstractfactory

Alguns Exemplos n Padrão criação n n n © 2003 Jaelson Castro Singleton Abstractfactory Builder Factory. Method Prototype Padrões de Projeto 21

Padrão de Criação: Singleton n Nome: Singleton (Único) Problema: Como pode ser construída uma

Padrão de Criação: Singleton n Nome: Singleton (Único) Problema: Como pode ser construída uma classe que só pode ter uma única instância e que pode ser acessada globalmente dentro da aplicação? Contexto: Em algumas aplicações uma classe deve ter exatamente uma instância. © 2003 Jaelson Castro Padrões de Projeto 22

Padrão de Criação: Singleton n Forças: n n Uma abordagem para tornar um objeto

Padrão de Criação: Singleton n Forças: n n Uma abordagem para tornar um objeto acessível globalmente é colocar a variável global, mas isto viola o encapsulamento. Outra abordagem é não criar uma instância de objeto em todo lugar, mas usar operações e atributos da classe (chamados `static´ em C++ e Java), mas isto limita a extensibilidade do modelo desde que a redefinição polimórfica das operações da classe não é possível em todos os ambientes de desenvolvimento (por exemplo C++) © 2003 Jaelson Castro Padrões de Projeto 23

Padrão de Criação: Singleton n Solução: n Criar uma classe com uma operação de

Padrão de Criação: Singleton n Solução: n Criar uma classe com uma operação de escopo de classe (ou estática, ex: Java, C++) get. Instance(), que: n n © 2003 Jaelson Castro Quando a classe é acessada pela primeira vez, a instância do objeto é criada e retornada para o cliente. Nos acessos subseqüentes de get. Instance() nenhuma instância adicional é criada, mas a identidade do objeto existente é retornado. Padrões de Projeto 24

Padrão de Criação: Singleton n Estrutura: Singleton static unique. Instance singleton. Data get. Instance()

Padrão de Criação: Singleton n Estrutura: Singleton static unique. Instance singleton. Data get. Instance() singleton. Operation() get. Singleton. Data() © 2003 Jaelson Castro return unique instance Padrões de Projeto 25

Padrão de Criação: Singleton n Vantagens: n n © 2003 Jaelson Castro Oferece acesso

Padrão de Criação: Singleton n Vantagens: n n © 2003 Jaelson Castro Oferece acesso controlado a única instância do objeto, pois a classe Singleton encapsula a instância. O espaço de nome não é necessariamente estendido com variáveis globais. A classe Singleton pode ter subclasses. Pode-se determinar que subclasses são instanciadas quando a classe Singleton é acessada pela primeira vez. Uma variação do padrão pode ser usada para criar um número específico de instâncias, se for requerido. Padrões de Projeto 26

Padrão Singleton – Exemplo Agate n n O sistema de gerenciamento de campanhas Agate

Padrão Singleton – Exemplo Agate n n O sistema de gerenciamento de campanhas Agate precisa guardar informações a respeito da empresa. Estas informações só devem ser guardadas em um lugar dentro da aplicação, mas serão usadas por diferentes objetos. © 2003 Jaelson Castro Padrões de Projeto 27

Padrão Singleton – Exemplo Agate n n Quando um objeto cliente precisa acessar o

Padrão Singleton – Exemplo Agate n n Quando um objeto cliente precisa acessar o objeto Company pode enviar a mensagem get. Company. Instance() e receber o identificador do objeto na resposta. O objeto cliente pode então enviar uma mensagem get. Companydetails() para o objeto Company © 2003 Jaelson Castro Padrões de Projeto 28

Padrão Singleton – Exemplo Agate n Mas ela opera como uma empresa separada em

Padrão Singleton – Exemplo Agate n Mas ela opera como uma empresa separada em cada país n © 2003 Jaelson Castro diferentes detalhes registrados da empresa para cada país Padrões de Projeto 29

Padrão Singleton –Agate n n A classe Company só é instanciada uma vez. Ela

Padrão Singleton –Agate n n A classe Company só é instanciada uma vez. Ela é acessível globalmente. Diferentes subclasses de Company que são instanciadas quando necessário, dependendo das circunstâncias em tempo de execução. © 2003 Jaelson Castro Padrões de Projeto 30

Padrão Abstract. Factory (kit) n Meta n n Provê uma interface para criar famílias

Padrão Abstract. Factory (kit) n Meta n n Provê uma interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas. Motivação n © 2003 Jaelson Castro Muitas vezes um programa necessita criar famílias inteiras de objetos que se relacionam entre si Padrões de Projeto 31

Abstract. Factory Estrutura do Padrão client Window Abstract. Factory create. Product. A() create. Product.

Abstract. Factory Estrutura do Padrão client Window Abstract. Factory create. Product. A() create. Product. B() Widget Factory abstract. Product. A product. A 2 Concrete. Factory 1 create. Product. A() create. Product. B() Concrete. Factory 2 create. Product. A() create. Product. B() Motif. Widget. Factory PMWidget. Factory © 2003 Jaelson Castro product. A 1 Scroll. Bar abstract. Product. B product. B 2 product. B 1 Padrões de Projeto 32

Abstract. Factory Participantes n Abstract. Factory n n Concrete. Factory n n Declara uma

Abstract. Factory Participantes n Abstract. Factory n n Concrete. Factory n n Declara uma interface para um tipo de objeto (produto) Concrete. Product n n Implementa a operações para criar objetos (produtos) concretos Abstract. Product n n Declara uma interface para operações que criam objetos (produtos) abstratos Define um objeto (produto) para ser criado pela Concrete. Factory correspondente Client n © 2003 Jaelson Castro Usa apenas interfaces declaradas pela Abstract. Factory e Abstract. Product Padrões de Projeto 33

Abstract. Factory Aplicabilidade n Use o Padrão Abstract. Factory quando: n n © 2003

Abstract. Factory Aplicabilidade n Use o Padrão Abstract. Factory quando: n n © 2003 Jaelson Castro Um sistema deve ser independente de como seus produtos são criados, compostos e representados Um sistema deve ser configurado com uma entre múltiplas famílias de produtos Uma família de produtos foi projetada para trabalhar em conjunto e você necessita garantir o cumprimento destas restrições Você quer fornecer uma biblioteca de produtos (biblioteca ou framework), mas quer revelar apenas as interfaces dos produtos, mas não suas implementações Padrões de Projeto 34

Abstract. Factory Colaborações n Normalmente uma única instância de uma fábrica concreta é criada

Abstract. Factory Colaborações n Normalmente uma única instância de uma fábrica concreta é criada em run-time n n n Esta fábrica concreta cria objetos (produtos) com uma implementação particular Para criar produtos diferentes, clientes devem usar fábricas concretas diferentes A Abstract. Factory transfere a criação de objetos para as subclasses (Concrete. Factory) © 2003 Jaelson Castro Padrões de Projeto 35

Abstract. Factory Conseqüências n n Isola Fábricas Concretas Facilita a Substituição de Famílias de

Abstract. Factory Conseqüências n n Isola Fábricas Concretas Facilita a Substituição de Famílias de Produtos Promove Consistência Entre Produtos Suporte a Novos Tipos de Produtos é difícil © 2003 Jaelson Castro Padrões de Projeto 36

Padrão Builder n Intenção n n Separar construção da implementação de um objeto complexo,

Padrão Builder n Intenção n n Separar construção da implementação de um objeto complexo, de modo que o mesmo processo de construção possa criar várias representações diferentes Motivação n n © 2003 Jaelson Castro Um programa muitas vezes necessita ler um formato de documento (fonte) e convertê-lo em vários outros formatos diferentes (objeto). Se os formatos (objeto) não são definidos a priori, é possível configurar o programa com um conversor (builder) que pode ser especializado em diferentes formatos e operações de conversão Padrões de Projeto 37

Padrão Builder Estrutura e Participantes Director construct() builders builder Abstract. Builder RTFReader for all

Padrão Builder Estrutura e Participantes Director construct() builders builder Abstract. Builder RTFReader for all objects in structure { builder. build. Part(); } build. Part() ASCIIConverter Te. XConverter Word. Converter Concrete. Builder 1 Concrete. Builder 2 Concrete. Builde 3 r build. Part() get. Result() Product 1 © 2003 Jaelson Castro Text. Converter ASCIIText Product 2 Te. XText Product 3 Word. Text Padrões de Projeto 38

Padrão Builder Colaborações a. Client a. Director a. Builder = new Concrete. Builder() a.

Padrão Builder Colaborações a. Client a. Director a. Builder = new Concrete. Builder() a. Director = new Director(a. Builder) a. Director. construct() a. Builder. build. Part. A() a. Builder. build. Part. B() a. Builder. build. Part. C() a. Builder. get. Result() © 2003 Jaelson Castro Padrões de Projeto 39

Padrão Builder Aplicabilidade e Conseqüências n Use o Padrão Builder quando n n n

Padrão Builder Aplicabilidade e Conseqüências n Use o Padrão Builder quando n n n O algoritmo para criar um objeto complexo deve ser independente das partes que constróem o objeto e de como elas são montadas O processo de construção necessita fornecer representações diferentes para o objeto que é construído Conseqüências do Padrão Builder n n n © 2003 Jaelson Castro Permite variar a representação interna de um produto Isola os códigos de construção e representação Permite controle fino sobre o processo de construção Padrões de Projeto 40

Padrão Factory. Method n Intenção n n Definir uma interface para criação de um

Padrão Factory. Method n Intenção n n Definir uma interface para criação de um objeto, mas deixar que subclasses decidam as classes dos objetos a instanciar Motivação n © 2003 Jaelson Castro Frameworks para criação de aplicações que trabalham sobre documentos necessitam ser refinados para definir exatamente qual a aplicação a ser criada, e qual o tipo de documento sobre a qual ela vai trabalhar Padrões de Projeto 41

Padrão Factory. Method Estrutura e Participantes Application Document Creator Product factory. Method() operation() Concrete.

Padrão Factory. Method Estrutura e Participantes Application Document Creator Product factory. Method() operation() Concrete. Product Concrete. Creator factory. Method() . . . Product p = factory. Method(); . . . return new Concrete. Product(); My. Document My. Application © 2003 Jaelson Castro Padrões de Projeto 42

Padrão Factory. Method Aplicabilidade e Conseqüências n Use o Padrão Factory. Method quando: n

Padrão Factory. Method Aplicabilidade e Conseqüências n Use o Padrão Factory. Method quando: n n Uma classe não pode antecipar qual a classe do objeto que ela deve criar. Uma classe quer que suas subclasses definam o objeto que elas criam Classes delegam responsabilidades para uma entre muitas subclasses auxiliares, e você quer limitar o conhecimento de qual subclasse auxiliar recebeu a delegação. Conseqüências n n n © 2003 Jaelson Castro Eliminam a necessidade de ligar classes específicas ao código Clientes necessitam criar subclasses sempre que precisam criar produtos Conectam hierarquias de classes paralelas Padrões de Projeto 43

Padrão Prototype n Intenção n n Especificar os tipos de objetos a criar usando

Padrão Prototype n Intenção n n Especificar os tipos de objetos a criar usando uma instância prototípica, e criar novos objetos através da clonagem deste protótipo Motivação n © 2003 Jaelson Castro Você deseja parametrizar o funcionamento de uma parte da aplicação mas não quer usar herança, pois a quantidade de subclasses diferentes seria muito grande Padrões de Projeto 44

Padrão Prototype Participantes e Colaboradores Ferramenta. Gráfica Cliente Gráfico prototype Prototype clone() operation() .

Padrão Prototype Participantes e Colaboradores Ferramenta. Gráfica Cliente Gráfico prototype Prototype clone() operation() . . . p = prototype. clone(); . . . Concrete. Prototype 1 Concrete. Prototype 2 clone() Pauta © 2003 Jaelson Castro Breve Padrões de Projeto 45

Padrão Prototype Aplicabilidade n Use o Padrão Prototype Quando: n Um sistema deve ser

Padrão Prototype Aplicabilidade n Use o Padrão Prototype Quando: n Um sistema deve ser independente de como seus produtos são criados, compostos e representados, e n n © 2003 Jaelson Castro Quando as classes a instanciar são especificadas em runtime, por exemplo, através de carga dinâmica, ou; Quando instâncias de uma classe podem ter apenas poucas combinações de estados. Fica então mais conveniente clonar objetos em vez de construir novos objetos Padrões de Projeto 46

Padrão Prototype Conseqüências n n Reduz o número de classes que os clientes conhecem

Padrão Prototype Conseqüências n n Reduz o número de classes que os clientes conhecem Permitem n n n n Que o cliente trabalhe com classes específicas de uma aplicação, sem necessidade de recompilação Adicionar e remover produtos em run-time Especificar novos objetos através da variação de valores Especificar novos objetos através de variação na estrutura Reduzir o número de subclasses Configuração dinâmica de aplicações Cada subclasse deve implementar o método clone() © 2003 Jaelson Castro Padrões de Projeto 47

Padrão Estrutural n Tratam de compor classes e objetos para formar estruturas grandes e

Padrão Estrutural n Tratam de compor classes e objetos para formar estruturas grandes e complexas © 2003 Jaelson Castro Padrões de Projeto 48

Padrão Estrutural: Exemplo n n n n Composite Adapter Bridge Decorator Facade Flyweight Proxy

Padrão Estrutural: Exemplo n n n n Composite Adapter Bridge Decorator Facade Flyweight Proxy © 2003 Jaelson Castro Padrões de Projeto 49

Padrão Estrutural: Composite n n n Nome: Composto Problema: Existe um requisito para representar

Padrão Estrutural: Composite n n n Nome: Composto Problema: Existe um requisito para representar hierarquias todo-parte, então ambos objetos (todo e parte) oferecem a mesma interface para objetos do cliente. Contexto: Numa aplicação tanto o objeto que contém quanto o que é componente são requeridos para oferecer o mesmo comportamento. n © 2003 Jaelson Castro Objetos cliente devem ser capazes de tratar objetos compostos ou componentes do mesmo jeito (ex. : graphical drawing package) Padrões de Projeto 50

Padrão Estrutural: Composite n Forças: n O requisito que os objetos, tanto composto componente,

Padrão Estrutural: Composite n Forças: n O requisito que os objetos, tanto composto componente, ofereçam a mesma interface, sugere que eles pertençam a mesma hierarquia de herança. n n © 2003 Jaelson Castro Isto permite que operações sejam herdadas e redefinidas com a mesma assinatura (polimorfismo). A necessidade de representar hierarquias todoparte indica a necessidade para uma estrutura de agregação Padrões de Projeto 51

Padrão Estrutural: Composite n Solução : Combinar hierarquias de herança e agregação. © 2003

Padrão Estrutural: Composite n Solução : Combinar hierarquias de herança e agregação. © 2003 Jaelson Castro Padrões de Projeto 52

Padrão Estrutural: Composite n Solução: n Ambas subclasses, Leaf e Composite, têm uma operação

Padrão Estrutural: Composite n Solução: n Ambas subclasses, Leaf e Composite, têm uma operação redefinida usando o polimorfismo an. Operation(). n n Na classe Composite esta operação redefinida invoca a operação relevante a partir de seus componentes usando um loop. A subclasse Composite também tem operações adicionais para gerenciar a hierarquia de agregação, então os componentes podem ser adicionados ou removidos. © 2003 Jaelson Castro Padrões de Projeto 53

Padrão Composite : Graphical drawing package 0. . * © 2003 Jaelson Castro Padrões

Padrão Composite : Graphical drawing package 0. . * © 2003 Jaelson Castro Padrões de Projeto 54

Padrão Composite : Agate © 2003 Jaelson Castro Padrões de Projeto 55

Padrão Composite : Agate © 2003 Jaelson Castro Padrões de Projeto 55

Padrão Adapter n Intenção n n Converter a interface de uma classe em outra

Padrão Adapter n Intenção n n Converter a interface de uma classe em outra interface que clientes possam utilizar. Compatibiliza classes, permitindo que trabalhem em conjunto. Motivação n n © 2003 Jaelson Castro Algumas vezes uma classe (de um toolkit) não é reusável somente porque sua interface não é compatível com a interface de uma aplicação de um domínio específico. A solução é criar um objeto adaptador, que encapsule e filtre as especificidades da classe adaptada, fornecendo uma interface que a aplicação espera utilizar Padrões de Projeto 56

Padrão (Class)Adapter Estrutura e Participantes n Usando Herança Múltipla Client Target Adaptee request() specific.

Padrão (Class)Adapter Estrutura e Participantes n Usando Herança Múltipla Client Target Adaptee request() specific. Request() Adapter request() © 2003 Jaelson Castro specific. Request() Padrões de Projeto 57

Padrão (Object)Adapter Estrutura e Participantes n Usando Composição Client Target Text. View Shape Adaptee

Padrão (Object)Adapter Estrutura e Participantes n Usando Composição Client Target Text. View Shape Adaptee request() specific. Request() Drawing. Editor Adapter adaptee request() adaptee. specific. Request(); Text. Shape © 2003 Jaelson Castro Padrões de Projeto 58

Padrão Adapter Aplicabilidade n Use o Padrão Adapter quando: n n n © 2003

Padrão Adapter Aplicabilidade n Use o Padrão Adapter quando: n n n © 2003 Jaelson Castro Você quer usar uma classe existente, e sua interface não é compatível com uma que você criou Você quer criar uma classe reusável que coopera com classes não relacionadas ou não previstas a priori, isto é, classes que não apresentam necessariamente a mesma interface (Somente para Object. Adapter) Você precisa usar várias subclasses existentes (de Adaptee), mas é impraticável adaptar as interfaces de cada uma através de herança. Um Object. Adapter pode resolver isto adaptando abstratamente a interface da superclasse. Padrões de Projeto 59

Padrão Adapter Conseqüências n Class. Adapter n n n Adapta uma classe concreta, mas

Padrão Adapter Conseqüências n Class. Adapter n n n Adapta uma classe concreta, mas NÃO SUAS SUBCLASSES Pode sobrepor alguns comportamentos do adaptado, visto que é uma subclasse da classe adaptada Object. Adapter n n © 2003 Jaelson Castro Permite que um único Adapter trabalhe com muitos adaptados. Ou seja, o próprio Adaptee e suas subclasses. Pode adicionar funcionalidade extra a todos os adaptados de uma só vez. Padrões de Projeto 60

Padrão Bridge n Intenção n n Desacoplar uma abstração de sua implementação, de modo

Padrão Bridge n Intenção n n Desacoplar uma abstração de sua implementação, de modo que as duas possam variar independentemente. Motivação n n n © 2003 Jaelson Castro Quando uma abstração pode ter várias implementações a solução usual é acomodar todas as implementações através de herança No entanto, herança liga de forma permanente uma abstração a uma implementação O padrão Bridge permite colocar as abstrações e suas implementações em diferentes hierarquias de classes, e permite que variem de forma independente Padrões de Projeto 61

Padrão Bridge Estrutura e Colaboradores Client Window. Imp Window imp Abstraction Implementor operation. Imp()

Padrão Bridge Estrutura e Colaboradores Client Window. Imp Window imp Abstraction Implementor operation. Imp() operation() imp. operation. Impl(); Refined. Abstraction Icon. Window © 2003 Jaelson Castro Concrete. Implementor. A Concrete. Implementor. B operation. Imp() XWindow. Imp PMWindow. Imp Padrões de Projeto 62

Padrão Bridge Aplicabilidade n Use o Padrão Bridge Quando: n n n © 2003

Padrão Bridge Aplicabilidade n Use o Padrão Bridge Quando: n n n © 2003 Jaelson Castro Você quer evitar ligação permanente entre uma abstração e sua implementação. Pode ser, por exemplo, quando se deseja variar a implementação em run-time Tanto a abstração quanto a implementação devem ser extensíveis através de herança Mudanças na implementação de uma abstração não devem ter impacto sobre o cliente Padrões de Projeto 63

Padrão Bridge Conseqüências n Desacoplamento entre interface e implementação n n Extensibilidade incrementada n

Padrão Bridge Conseqüências n Desacoplamento entre interface e implementação n n Extensibilidade incrementada n n Implementação de uma abstração configurada em run-time Eliminação de dependências de compilação Criação de camadas de abstração que podem melhor estruturar o sistema Herança para abstração e implementação Detalhes de implementação são escondidos do cliente © 2003 Jaelson Castro Padrões de Projeto 64

Padrão Decorator n Intenção n n Anexa dinamicamente responsabilidades adicionais a um objeto. Provê

Padrão Decorator n Intenção n n Anexa dinamicamente responsabilidades adicionais a um objeto. Provê uma alternativa flexível ao uso de herança como modo de estender funcionalidade. Motivação n n n © 2003 Jaelson Castro Algumas vezes se quer 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 um scrollbar a uma área de texto. Uma forma de se acrescentar responsabilidades é através de herança, mas isto torna o projeto inflexível, pois a escolha da borda é definida em tempo de compilação. Neste caso o cliente não pode controlar como, onde e quando decorar o componente com uma borda. Uma abordagem mais flexível é inserir o componente em outro objeto que adiciona a borda, um Decorator. Padrões de Projeto 65

Padrão Decorator Estrutura e Participantes Component Visual. Component operation() Text. View Concrete. Component Decorator

Padrão Decorator Estrutura e Participantes Component Visual. Component operation() Text. View Concrete. Component Decorator operation() component Concrete. Decorator. A Concrete. Decorator. B operation() added. Behavior() added. State Border. Decorator © 2003 Jaelson Castro component. operation(); super. operation(); added. Behavior(); Scroll. Decorator Padrões de Projeto 66

Padrão Decorator Aplicabilidade n Use o padrão Decorator: n n Para adicionar responsabilidades a

Padrão Decorator Aplicabilidade n Use o padrão Decorator: n n Para adicionar responsabilidades a objetos individuais de forma dinâmica e transparente, sem afetar outros objetos Para responsabilidades que podem ser removidas Quando extensão através de herança é impraticável. Algumas vezes uma grande quantidade de extensões independentes são possíveis e seria necessário um imenso número de subclasses para suportar cada combinação possível entre elas. Conseqüências n n © 2003 Jaelson Castro Mais flexibilidade que herança Evita incorporação forçada de comportamentos desnecessários Padrões de Projeto 67

Padrão Facade n Intenção n n Prover uma interface unificada para o conjunto de

Padrão Facade n Intenção n n Prover uma interface unificada para o conjunto de interfaces de um subsistema. Define uma interface de alto nível que faz um subsistema mais fácil de usar. Motivação n © 2003 Jaelson Castro Estruturar um sistema em subsistemas contribui para reduzir sua complexidade. A dependência entre subsistemas pode ser minimizada através do uso de um objeto Fachada, o qual provê uma interface única e uniforme para as diversas funcionalidades de um subsistema. Padrões de Projeto 68

Padrão Facade Estrutura e Participantes Client subsystem classes Compilador Facade Scanner Parser Token ©

Padrão Facade Estrutura e Participantes Client subsystem classes Compilador Facade Scanner Parser Token © 2003 Jaelson Castro Padrões de Projeto 69

Padrão Facade Aplicabilidade n Use o Padrão Facade quando: n n n © 2003

Padrão Facade Aplicabilidade n Use o Padrão Facade quando: n n n © 2003 Jaelson Castro Você quer prover uma interface simplificada para um subsistema complexo. Um Facade pode prover uma visão simples e default do subsistema, suficiente para a maioria dos clientes Existem muitas dependências entre clientes e classes da implementação. O Facade reduz esta dependência e promove independência e portabilidade Você quer criar sistemas em camadas. Um Facade provê o ponto de entrada para cada camada (nível) do subsistema. Padrões de Projeto 70

Padrão Facade Conseqüências n n Protege os clientes dos componentes do subsistema Promove acoplamento

Padrão Facade Conseqüências n n Protege os clientes dos componentes do subsistema Promove acoplamento fraco entre o subsistema e seus clientes n n n Reduz dependências de compilação Facilita a portabilidade do sistema Não evita que aplicações possam acessar diretamente as subclasses do sistema, se assim o desejarem. © 2003 Jaelson Castro Padrões de Projeto 71

Padrão Flyweight n Intenção n n Usar compartilhamento para suportar uma grande quantidade de

Padrão Flyweight n Intenção n n Usar compartilhamento para suportar uma grande quantidade de objetos de baixa granularidade de forma eficiente. Motivação n n n © 2003 Jaelson Castro Algumas aplicações podem se beneficiar do uso de objetos em seu projeto, mas uma implementação ingênua pode tornar este uso proibitivamente dispendioso (principalmente o consumo de memória) Um Flyweight é um objeto compartilhado que pode ser usado em múltiplos contextos simultaneamente, porque possui um estado intrínseco (comum a todos os contextos) e se utiliza de vários estados extrínsecos (particulares a cada contexto onde o Flyweight é usado). Clientes são responsáveis por passar o estado extrínseco ao Padrões de Projeto 72 Flyweight quando vão utilizá-lo.

Padrão Flyweight Estrutura e Colaboradores Flyweight. Factory imp Flyweight Glyph Operation(extrinsinc. State) get. Flyweight(key)

Padrão Flyweight Estrutura e Colaboradores Flyweight. Factory imp Flyweight Glyph Operation(extrinsinc. State) get. Flyweight(key) If (flyweight[key] exists) { return existing flyweight } else { create new flyweight; add it to pool of flyweights; return the new flyweight; } Client © 2003 Jaelson Castro Concrete. Flyweight Unshared. Concrete. Flyweight Operation(extrinsinc. State) intrinsinc. State all. State Character Row, Collumn Padrões de Projeto 73

Padrão Flyweight Aplicabilidade n Use o Padrão Flyweight quando TODAS as condições abaixo forem

Padrão Flyweight Aplicabilidade n Use o Padrão Flyweight quando TODAS as condições abaixo forem verdadeiras: n n n © 2003 Jaelson Castro A aplicação usa uma grande quantidade de objetos Custos de armazenamento são altos, por causa da imensa quantidade de objetos Parte considerável do estado do objeto pode se tornar extrínseco Uma vez que o estado extrínseco é removido, muitos agrupamentos de objetos podem ser substituídos por uma quantidade consideravelmente menor de objetos compartilhados A aplicação não depende de identidade de objetos. Visto que flyweights podem ser compartilhados, testes de identidade irão retornar true para objetos conceitualmente distintos. Padrões de Projeto 74

Padrão Flyweight Conseqüências n n Custos de run-time associados com transferência, busca e/ou computação

Padrão Flyweight Conseqüências n n Custos de run-time associados com transferência, busca e/ou computação do estado extrínseco. Tais custos são compensados pela economia em uso de memória, à medida que mais flyweights são criados. Redução de consumo de memória é função de: n n n © 2003 Jaelson Castro redução do número total de instâncias resultantes do compartilhamento quantidade de estado intrínseco por objeto Se o estado extrínseco é armazenado ou Padrões de Projeto 75

Padrão Proxy n Intenção n n Prover um representante para outro objeto de modo

Padrão Proxy n Intenção n n Prover um representante para outro objeto de modo a controlar o acesso a este Motivação n Várias razões para controlar acesso a um objeto, como por exemplo: n n n © 2003 Jaelson Castro deferir o custo de criação e inicialização para o momento de uso (objetos sob demanda); Prover um representante local para um objeto remoto; Proteger o objeto original. Padrões de Projeto 76

Padrão Proxy Estrutura e Colaboradores Subject Client request() Real. Subject Proxy request(). . .

Padrão Proxy Estrutura e Colaboradores Subject Client request() Real. Subject Proxy request(). . . Image © 2003 Jaelson Castro Graphic real. Subject. request(); Image. Proxy Padrões de Projeto 77

Padrão Proxy Conseqüências n Acrescenta um nível de indireção adicional © 2003 Jaelson Castro

Padrão Proxy Conseqüências n Acrescenta um nível de indireção adicional © 2003 Jaelson Castro Padrões de Projeto 79

Padrão Comportamental n Preocupam-se com algoritmos e a atribuição de responsabilidades entre objetos. Descrevem

Padrão Comportamental n Preocupam-se com algoritmos e a atribuição de responsabilidades entre objetos. Descrevem padrões de comunicação entre os objetos. © 2003 Jaelson Castro Padrões de Projeto 80

Alguns Exemplos n De Objeto n n n Baseados no uso de composição State,

Alguns Exemplos n De Objeto n n n Baseados no uso de composição State, Chain of Responsability, Command, Mediator, Observer, Strategy, Visitor, Iterator, Memento De Classe n n n © 2003 Jaelson Castro Baseados no uso de herança Template Method Interpreter Padrões de Projeto 81

Padrão Comportamental: State n n n Nome: State Problema: Um objeto exibe um comportamento

Padrão Comportamental: State n n n Nome: State Problema: Um objeto exibe um comportamento diferente quando seu estado interno muda, fazendo o objeto parecer ter mudado a classe em tempo de execução. Contexto: Ema algumas aplicações um objeto pode ter o comportamento complexo que seja dependente do seu estado. A resposta para uma mensagem específica varia de acordo com o estado do objeto. © 2003 Jaelson Castro Padrões de Projeto 82

Padrão Comportamental: State n Forças: n O objeto tem comportamento complexo que deve ser

Padrão Comportamental: State n Forças: n O objeto tem comportamento complexo que deve ser dividido em elementos menos complexos. Uma ou mais operações têm comportamento que variam de acordo com o estado do objeto. n Tipicamente a operação teria muitas sentenças condicionais dependentes do estado. n Uma abordagem é ter operações públicas separadas para cada estado, mas objetos cliente precisam saber o estado do objeto para poderem chamar a operação adequada © 2003 Jaelson Castro Padrões de Projeto 83

Padrão Comportamental: State n Solução: n n Separar o estado dependente do comportamento do

Padrão Comportamental: State n Solução: n n Separar o estado dependente do comportamento do objeto original e alocar este comportamento para um série de outros objetos, um para cada estado. Estes objetos estado têm apenas responsabilidade para o comportamento daquele estado. Context operation( ) State {abstract} operation( ) Concrete. State. A Operation( ) © 2003 Jaelson Castro Concrete. State. B Operation( ) Padrões de Projeto 84

Participantes do Padrão State Contexto define a interface de interesse para clientes mantém uma

Participantes do Padrão State Contexto define a interface de interesse para clientes mantém uma instância de uma subclasse Concrete. State que define o estado corrente Estado define uma interface para encapsulamento do comportamento associado com um estado específico do Contexto Subclasses Concrete. State cada subclasse implementa um comportamento associado com um estado do Contexto © 2003 Jaelson Castro Padrões de Projeto 85

Padrão Comportamental: State n Vantagens: n n © 2003 Jaelson Castro Comportamento do estado

Padrão Comportamental: State n Vantagens: n n © 2003 Jaelson Castro Comportamento do estado é localizado e o comportamento para diferentes estados é separado. Isto facilita qualquer modificação do comportamento do estado, em particular a adição de estados extra. Transições de estado são explícitas. O objeto estado que está ativo, indica o estado atual do objeto Contexto. Padrões de Projeto 86

Padrão Comportamental: State n Desvantagens: n Objeto estado pode ser criado e removido quando

Padrão Comportamental: State n Desvantagens: n Objeto estado pode ser criado e removido quando o objeto Contexto muda o estado, introduzindo assim um overhead no processamento. n O uso do padrão estado introduz pelo menos uma mensagem extra, a mensagem da classe Contexto para classe Estado, adicionando assim mais overhead no processamento. © 2003 Jaelson Castro Padrões de Projeto 87

Padrão State : Um Sistema de Biblioteca Copy Check. Out Loan. Status {abstract} Check.

Padrão State : Um Sistema de Biblioteca Copy Check. Out Loan. Status {abstract} Check. Out On. Loan Available Check. Out • As subclasses concretas definem o método de acordo com o estado que elas representam Available: : Check. Out (book; On. Loan: : Check. Out (book; user) //Check out book to a //Error: ‘Book already out’ user © 2003 Jaelson Castro Padrões de Projeto 88

Padrão State : Agate © 2003 Jaelson Castro Padrões de Projeto 89

Padrão State : Agate © 2003 Jaelson Castro Padrões de Projeto 89

Padrão Chain of Responsability n Intenção n n Evita o acoplamento do remetente de

Padrão Chain of Responsability n Intenção n n Evita o acoplamento do remetente de uma solicitação ao seu receptor, ao dar a mais de um objeto a oportunidade de tratar uma solicitação. Encadeia os objetos receptores, passando a solicitação ao longo da cadeia até que um objeto a trate. Motivação n © 2003 Jaelson Castro Help sensível ao contexto: O usuário pode obter ajuda em qualquer parte da interface simplesmente pressionando o botão do mouse sobre ela. A ajuda depende da parte selecionada e do seu contexto. Padrões de Projeto 90

Chain of Responsability Estrutura do Padrão Help. Handler Handle. Request() client Concrete. Handler 1

Chain of Responsability Estrutura do Padrão Help. Handler Handle. Request() client Concrete. Handler 1 Handle. Request() Print. Button © 2003 Jaelson Castro sucessor Concrete. Handler 2 Handle. Request() Print. Dialogue Padrões de Projeto 91

Chain of Responsability Participantes n Handler n n n Concrete. Handler n n Define

Chain of Responsability Participantes n Handler n n n Concrete. Handler n n Define uma interface para tratar solicitações. Implementa o elo ao sucessor. Trata de solicitações pelas quais é responsável. Pode acessar o seu sucessor. Se o Concrete. Handler pode tratar a solicitação, ele o faz; caso contrário, ele a repassa para o seu sucessor. Client n © 2003 Jaelson Castro Inicia a solicitação para um objeto Concrete. Handler da cadeia. Padrões de Projeto 92

Chain of Responsability Aplicabilidade n Use o Padrão Chain of Responsability quando: n n

Chain of Responsability Aplicabilidade n Use o Padrão Chain of Responsability quando: n n n © 2003 Jaelson Castro Mais de um objeto pode tratar uma solicitação e o objeto que a tratará não é conhecido a priori. O objeto que trata a solicitação deve ser escolhido automaticamente; Você quer emitir uma solicitação para um dentre vários objetos, sem especificar explicitamente o receptor; O conjunto de objetos que pode tratar uma solicitação deve ser especificado dinamicamente. Padrões de Projeto 93

Chain of Responsability Colaborações n Quando um cliente emite uma solicitação, a mesma se

Chain of Responsability Colaborações n Quando um cliente emite uma solicitação, a mesma se propaga ao longo da cadeia até que um objeto Concrete. Handler assume a responsabilidade de tratá-la. © 2003 Jaelson Castro Padrões de Projeto 94

Chain of Responsability Conseqüências n n n Acoplamento reduzido entre cliente e receptor Flexibilidade

Chain of Responsability Conseqüências n n n Acoplamento reduzido entre cliente e receptor Flexibilidade na atribuição de responsabilidades a objetos. A cadeia pode ser modificada em tempo de execução A solicitação não é garantida de ser tratada © 2003 Jaelson Castro Padrões de Projeto 95

Padrão Iterator n Intenção n n Fornecer um meio de acessar, sequencialmente, os elementos

Padrão Iterator n Intenção n n Fornecer um meio de acessar, sequencialmente, os elementos de um objeto agregado sem expor a sua representação interna. Motivação List Count() Append(Element) Remove(Element). . . © 2003 Jaelson Castro list List. Iterator First() Next() Is. Done() Current. Item() Padrões de Projeto 96

Padrão Iterator Estrutura Aggregate Create. Iterator() client Concrete. Aggregate Create. Iterator() Iterator First() Next()

Padrão Iterator Estrutura Aggregate Create. Iterator() client Concrete. Aggregate Create. Iterator() Iterator First() Next() Is. Done() Current. Item() Concrete. Iterator Return new Concrete. Ierator(this) © 2003 Jaelson Castro Padrões de Projeto 97

Iterator Participantes n Iterator n n Concrete. Iterator n n n Implementa a interface

Iterator Participantes n Iterator n n Concrete. Iterator n n n Implementa a interface de Iterator. Mantém o controle da posição corrente no percurso do agregado. Aggregate n n Define uma interface para acessar e percorrer elementos. Define uma interface para a criação de um objeto Iterator. Concrete. Aggregate n © 2003 Jaelson Castro Implementa a interface de criação do Iterator para retornar uma instância do Concrete. Iterator apropriado. Padrões de Projeto 98

Padrão Iterator Colaborações n Um Concrete. Iterator mantém o controle do objeto corrente no

Padrão Iterator Colaborações n Um Concrete. Iterator mantém o controle do objeto corrente no agregado e pode computar o objeto sucessor no percurso. © 2003 Jaelson Castro Padrões de Projeto 99

Padrão Iterator Aplicabilidade n n Para acessar os conteúdos de um objeto agregado sem

Padrão Iterator Aplicabilidade n n Para acessar os conteúdos de um objeto agregado sem expor a sua representação interna; Para fornecer uma interface uniforme que percorra diferentes estruturas agregadas (iteração polimórfica). © 2003 Jaelson Castro Padrões de Projeto 100

Padrão Observer n Intenção n n Definir uma dependência um-para-muitos entre objetos, de maneira

Padrão Observer n Intenção n n Definir uma dependência um-para-muitos entre objetos, de maneira que quando um objeto muda o seu estado todos os seus dependentes são notificados e atualizados automaticamente. Motivação n © 2003 Jaelson Castro Separação das classes de apresentação das classes de aplicação (ex: visualizadores para C e Java de árvores sintáticas) Padrões de Projeto 101

Padrão Observer Estrutura Subject Attach(Observer) Dettach(Observer) Notify() Concrete. Subject Get. State() Set. State() subject.

Padrão Observer Estrutura Subject Attach(Observer) Dettach(Observer) Notify() Concrete. Subject Get. State() Set. State() subject. State © 2003 Jaelson Castro observers Observer Update() For all o in observers { o. Update } subject return subject. State; Concrete. Observer Update() observer. State = subject. Get. State; Padrões de Projeto 102

Padrão Observer Participantes n Subject n n n Observer n n Conhece os seus

Padrão Observer Participantes n Subject n n n Observer n n Conhece os seus observadores. Um número qualquer de objetos Observer pode observar um subject. Fornece uma interface para acrescentar e remover objetos observers. Define uma interface de atualização para objetos que devem ser notificados sobre mudanças em um Subject. Concrete. Subject n n © 2003 Jaelson Castro Armazena estados de interesse para objetos Concrete. Observer. Envia uma notificação para os seus observadores quando seu estado muda. Padrões de Projeto 103

Padrão Observer Participantes n Concrete. Observer n n n © 2003 Jaelson Castro Mantém

Padrão Observer Participantes n Concrete. Observer n n n © 2003 Jaelson Castro Mantém uma referência para um objeto Concrete. Subject. Armazena estados que devem permanecer consistentes com os do Subject. Implementa a interface de atualização de Observer, para manter seu estado consistente com o do subject. Padrões de Projeto 104

Padrão Observer Colaborações n n O Concrete. Subject notifica seus observadores sempre que ocorrer

Padrão Observer Colaborações n n O Concrete. Subject notifica seus observadores sempre que ocorrer uma mudança que pode tornar inconsistente o estado deles com o seu próprio. Após ter sido informado de uma mudança no subject concreto, um objeto Concrete. Observer pode consultar o subject para obter informações. O Concrete. Observer usa esta informação para reconciliar o seu estado com aquele do subject. © 2003 Jaelson Castro Padrões de Projeto 105

Padrão Observer Aplicabilidade n n Quando uma abstração tem dois aspectos, um dependente do

Padrão Observer Aplicabilidade n n Quando uma abstração tem dois aspectos, um dependente do outro. Encapsulando esses aspectos em objetos separados, permite-se variá-los e reutilizá-los independentemente. Quando uma mudança em um objeto exige mudanças em outros, e você não sabe quantos objetos necessitam ser mudados. © 2003 Jaelson Castro Padrões de Projeto 106

Padrões GOF 23 Criação (5) n Estrutura (7) n Comportamento (11) n © 2003

Padrões GOF 23 Criação (5) n Estrutura (7) n Comportamento (11) n © 2003 Jaelson Castro Padrões de Projeto 107

Padrões de Criação: Objeto n Único (Singleton) n n Fábrica Abstrata (Abstract Factory) n

Padrões de Criação: Objeto n Único (Singleton) n n Fábrica Abstrata (Abstract Factory) n n Oferece uma interface para criar famílias de objetos relacionados sem especificar suas classes concretas. Construtor (Builder) n n Garante que uma classe tenha apenas uma única instância, e oferece um ponto global para acessá-la. Separa a construção de um objeto complexo de sua representação, então o mesmo processo de construção pode criar diferentes representações. Protótipo (Prototype) n Especifica os tipos de objetos para criar usando uma instância prototípica, e cria novos objetos copiando deste protótipo. © 2003 Jaelson Castro Padrões de Projeto 108

Padrões de Criação: Classe n Método Factory n Define uma interface para criação de

Padrões de Criação: Classe n Método Factory n Define uma interface para criação de um objeto, mas deixa a subclasse decidir que classe instancia. n Permite a classe retardar a instanciação da subclasse. © 2003 Jaelson Castro Padrões de Projeto 109

Padrões Estruturais: Objeto n Adaptador (Adapter) n n Ponte (Bridge) n n Converte a

Padrões Estruturais: Objeto n Adaptador (Adapter) n n Ponte (Bridge) n n Converte a interface de uma classe em outra interface que os clientes esperam. Desacopla uma abstração da sua implementação, as duas podem variar independentemente (herança em tempo de execução) Composto (Composite) n Compõe objetos em três estruturas para representar hierarquias parte-todo. Composto permite que clientes tratem tanto os objetos individuais quanto as composições de objetos uniformemente. © 2003 Jaelson Castro Padrões de Projeto 110

Padrões Estruturais: Objeto n Decorador (Decorator) n n Fachada (Façade) n n Oferece uma

Padrões Estruturais: Objeto n Decorador (Decorator) n n Fachada (Façade) n n Oferece uma interface unificada para um conjunto de interfaces de um subsistema. Peso Mosca (Flyweight) n n Anexa responsabilidades adicionais para um objeto dinamicamente. Usa compartilhamento para apoiar um grande número de objetos de fina granularidade eficientemente. Proxy n © 2003 Jaelson Castro Oferece lugar de acesso para outro objeto controlar o acesso. Padrões de Projeto 111

Padrões Estruturais: Classe n n Adaptador (Adapter) n Converte a interface de uma classe

Padrões Estruturais: Classe n n Adaptador (Adapter) n Converte a interface de uma classe para outra interface que os clientes esperam. Base de Template (Template Base) n Usa classes base do template para especificar associações. © 2003 Jaelson Castro Padrões de Projeto 112

Padrões Comportamentais: Objeto n Cadeia de Responsabilidade Evita o acoplamento do emissor de um

Padrões Comportamentais: Objeto n Cadeia de Responsabilidade Evita o acoplamento do emissor de um pedido ao seu receptor através da chance de mais de um objeto em mudar seu pedido Observador (Observer) n Quando um objeto muda de estado, todos os seus dependentes são notificados e atualizados automaticamente. n n © 2003 Jaelson Castro Padrões de Projeto 113

Padrões Comportamentais: Objeto (cont. ) n n Iteração (Iterator) n Oferece uma maneira para

Padrões Comportamentais: Objeto (cont. ) n n Iteração (Iterator) n Oferece uma maneira para acessar os elementos de um objeto agregado sequencialmente sem expor a sua representação. Mediador (Mediator) n Define um objeto que encapsula como um conjunto de objetos que interagem entre si. © 2003 Jaelson Castro Padrões de Projeto 114

Padrões Comportamentais: Objeto (cont. ) n Comando n Encapsula a requisição como um objeto.

Padrões Comportamentais: Objeto (cont. ) n Comando n Encapsula a requisição como um objeto. n “Memento” n Captura e externaliza um estado interno do objeto para que estado possa ser recuperado depois. Estado n Permite que um objeto altere seu comportamento quando seu estado interno muda. n © 2003 Jaelson Castro Padrões de Projeto 115

Padrões Comportamentais: Objeto (cont. ) n Estratégia n n Visitante n © 2003 Jaelson

Padrões Comportamentais: Objeto (cont. ) n Estratégia n n Visitante n © 2003 Jaelson Castro Define uma família de algoritmos, encapsula cada um, e torna-os intercambiáveis. Representa uma operação a ser realizada para os elementos da estrutura de um objeto. Padrões de Projeto 116

Padrões Comportamentais: Classe n n Interpretador n Dada uma linguagem, define uma representação para

Padrões Comportamentais: Classe n n Interpretador n Dada uma linguagem, define uma representação para sua gramática com um interpretador que usa a representação para interpretar sentenças na linguagem. Template de método n Permite que subclasses redefinam certos passos de um algoritmo sem alterar a estrutura do algoritmo. © 2003 Jaelson Castro Padrões de Projeto 117

Usando Padrões n n n Existe um padrão que trata um problema similar? O

Usando Padrões n n n Existe um padrão que trata um problema similar? O contexto do padrão é consistente com o problema real? As conseqüências do uso de padrão são aceitáveis? © 2003 Jaelson Castro Padrões de Projeto 118

Usando Padrões (cont. ) n n n O padrão dispara uma solução alternativa que

Usando Padrões (cont. ) n n n O padrão dispara uma solução alternativa que pode ser mais aceitável? Existe uma solução mais simples? Existem algumas restrições de conflito que sejam impostas pelo ambiente de software que está sendo usado? © 2003 Jaelson Castro Padrões de Projeto 119

Catálogo de Padrões n n n Padrões colecionados num catálogo precisam ser agrupados. Projetistas

Catálogo de Padrões n n n Padrões colecionados num catálogo precisam ser agrupados. Projetistas descobrindo novos padrões precisam considerar onde o seu novo padrão se encaixa no catálogo. Todos os usuários precisam ser atualizados no conteúdo do catálogo © 2003 Jaelson Castro Padrões de Projeto 120

Armazenando e Procurando Padrões Manutenção da documentação de padrões n Procura de facilidades disponíveis

Armazenando e Procurando Padrões Manutenção da documentação de padrões n Procura de facilidades disponíveis n Agrupamento de padrões n Publicação de padrões disponíveis n Uso de fontes, tipos, ênfase, etc. n © 2003 Jaelson Castro Padrões de Projeto 121

Benefícios do Uso de Padrões n n Eles oferecem um mecanismo para reusar soluções

Benefícios do Uso de Padrões n n Eles oferecem um mecanismo para reusar soluções genéricas. Eles oferecem um vocabulário para discutir o domínio do problema no mais alto nível de abstração, tornando mais fácil considerar aspectos micro arquiteturais. © 2003 Jaelson Castro Padrões de Projeto 122

Perigos do Uso de Padrões n n n Algumas pessoas acreditam que o uso

Perigos do Uso de Padrões n n n Algumas pessoas acreditam que o uso de padrões possa limitar a criatividade. O uso de padrões de uma maneira descontrolada pode originar projetos carregados. Desenvolvedores: n n © 2003 Jaelson Castro n Precisam de tempo para entender os catálogos de padrões relevantes Precisam de fácil acesso para catálogos relevantes Precisam ser treinados no uso de padrões Padrões de Projeto 123

Leituras Adicionais n Gamma E, Helm R, Johnson R and Vlissides J. Design Patterns:

Leituras Adicionais n Gamma E, Helm R, Johnson R and Vlissides J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley 1994. © 2003 Jaelson Castro Padrões de Projeto 124