Padrões de ProjetoPadrões de ProjetoConceitos e ImplementaçõesConceitos e Implementações

(1)

Módulo 2

Módulo 2 –– Orientação a ObjetosOrientação a Objetos

Coordenador: Giuliano Prado de Morais Giglio, M.Sc.

profgiuliano@yahoo.com.br

Padrões de Projeto Padrões de Projeto

Conceitos e Implementações Conceitos e Implementações

Padrões de Projeto de Software OO

n

Também conhecidos como

¨ Padrões de Desenho de Software OO

¨ ou simplesmente como Padrões.

A Inspiração

n A idéia de padrões foi apresentada por Christopher Alexander em 1977 no contexto de Arquitetura (de prédios e cidades):

Cada padrão descreve um problema que ocorre repetidamente de novo e de novo em nosso ambiente, e então descreve a parte central da solução para aquele problema de uma forma que você pode usar da solução para aquele problema de uma forma que você pode usar esta solução um milhão de vezes, sem nunca implementa-la duas vezes da mesma forma.

n Livros

¨ The Timeless Way of Building

¨ A Pattern Language: Towns, Buildings, and Construction

¨ serviram de inspiração para os desenvolvedores de software.

Catálogo de soluções

n Um padrão encerra o conhecimento de uma pessoa muito experiente em um determinado assunto de uma forma que este conhecimento pode ser transmitido para outras pessoas menos experientes.

menos experientes.

n Outras ciências (p.ex. química) e engenharias possuem catálogos de soluções.

n Desde 1995, o desenvolvimento de software passou a ter o seu primeiro catálogo de soluções para projeto de software: o livro GoF.

(2)

Gang of Four (GoF)

n

E. Gamma and R. Helm and R.

Johnson and J. Vlissides. Design

Patterns - Elements of Reusable Patterns - Elements of Reusable Object-Oriented Software.

Addison-Wesley, 1995.

Vantagens no uso de DP

n

Evita a redescoberta de soluções

n

Propicia o uso de soluções corretas

n

Melhora a qualidade do software

n

Melhora a confiabilidade do software

n

Melhora a confiabilidade do software

n

Provê uma linguagem comum entre desenvolvedores

n

Reduz o volume de documentação

n

Economiza esforço e tempo de desenvolvimento e manutenção

n

Conduz ao bom uso de orientação a objetos

Gang of Four (GoF)

n Passamos a ter um vocabulário comum para conversar sobre projetos de software.

n Soluções que não tinham nome passam a ter nome.

n Ao invés de discutirmos um sistema em termos de pilhas, filas, árvores e listas ligadas, passamos a falar de coisas de filas, árvores e listas ligadas, passamos a falar de coisas de muito mais alto nível como Fábricas, Fachadas, Observador, Estratégia, etc.

n A maioria dos autores eram entusiastas de Smalltalk, principalmente o Ralph Johnson.

n Mas acabaram baseando o livro em C++ para que o impacto junto à comunidade de CC fosse maior. E o impacto foi enorme, o livro vendeu centenas de milhares de cópias.

O Formato de um padrão

n

Todo padrão inclui

¨ Nome

¨ Problema

¨ Solução

Conseqüências / Forças

¨ Conseqüências / Forças

n

Existem outros tipos de padrões mas iremos nos

concentrar no GoF.

(3)

O Formato dos padrões no GoF

¨ Nome (inclui número da página)

n um bom nome é essencial para que o padrão caia na boca do povo

¨ Objetivo / Intenção

¨ Também Conhecido Como

¨ Motivação

n um cenário mostrando o problema e a necessidade da solução

¨ Aplicabilidade

n como reconhecer as situações nas quais o padrão é aplicável

¨ Estrutura

n uma representação gráfica da estrutura de classes do padrão (usando OMT91) em, às vezes, diagramas de interação (Booch 94)

¨ Participantes

n as classes e objetos que participam e quais são suas responsabilidades

¨ Colaborações

n como os participantes colaboram para exercer as suas responsabilidades

O Formato dos padrões no GoF

¨ Conseqüências

n vantagens e desvantagens, trade-offs

¨ Implementação

n com quais detalhes devemos nos preocupar quando implementamos o padrão

n aspectos específicos de cada linguagem

¨ Exemplo de Código

n no caso do GoF, em C++ (a maioria) ou Smalltalk

¨ Usos Conhecidos

n exemplos de sistemas reais de domínios diferentes onde o padrão é utilizado

¨ Padrões Relacionados

n quais outros padrões devem ser usados em conjunto com esse

n quais padrões são similares a este, quais são as dierenças

Tipos de Padrões de Projeto

n Categorias de Padrões do GoF

¨ Padrões Estruturais

¨ Padrões de Criação

¨ Padrões Comportamentais

n Vamos ver um exemplo de cada um deles.

Os 23 Padrões do GoF

Estruturais

n

Adapter

n Bridge

n Composite

n Decorator

n

Façade

n Flyweight

n

Proxy

(4)

Criação

n

Abstract Factory

n Builder

n

Factory Method

n Prototype

n

Singleton

Comportamentais

n Chain of Responsibility

n Command

n Interpreter

n Observer

n State

n Strategy

n Iterator

n Mediator

n Memento

n Template Method

n Visitor

Adapter

n

Objetivo: converter a interface de uma classe em outra interface esperada pelos clientes. Adapter permite a comunicação entre classes que não permite a comunicação entre classes que não

poderiam trabalhar juntas devido à incompatibilidade de suas interfaces." [GoF]

Adapter

n Muitas vezes uma ferramenta ou uma classe de biblioteca não pode ser usada, porque sua interface não é a requerida pela aplicação

n Não se pode mudar a interface, porque não se dispõe do código fonte

do código fonte

n Mesmo que se tivesse, não é interessante mudar a biblioteca a cada aplicação

n Padrão Adapter fornece um objeto com uma nova interface que se adapta à interface de outro objeto, permitindo a colaboração

n Análogo a adaptadores de tomadas elétricas

(5)

Adapter - Exemplo Adapter - Exemplo

Adapter – Notas práticas

n

Adapter livra das preocupações com as interfaces das classes existentes quando se está desenvolvendo um projeto.

n

Contando com uma classe que faça o que se

n

Contando com uma classe que faça o que se deseja, ao menos conceitualmente, sabe-se então que poderá usar o Adapter para fornecer a ela a interface concreta.

n

Se existirem classes pré-existentes, o padrão Adapter poderá ser usado para adaptá-las à classe abstrata apropriada.

Adapter – Notas práticas

n Dois tipos de padrão Adapter:

¨Adapter de Objeto: objeto adaptador contendo um objeto adaptado.

um objeto adaptado.

¨Adapter de Classe: utiliza-se herança múltipla

n A decisão sobre qual utilizar baseia-se nas diferentes funcionalidades no domínio do problema. Na

implementação, deve-se considerar mais as funções envolvidas.

(6)

Visão Tradicional x Nova Visão da OO

n Tradicionalmente, considera os objetos como dados com métodos ;

¨ Decorre-se da idéia de enxergar objetos a partir de uma perspectiva de implementação.

n Definição mais útil (perspectiva mais útil): um objeto é

n Definição mais útil (perspectiva mais útil): um objeto é uma entidade com responsabilidades e estas fornecem a ele seu comportamento.

n Ajuda a focar o que os objetos devem fazer, e não simplesmente como implementá-los, o que possibilita construir software a partir de dois passos:

¨ Elaborar um projeto preliminar sem se preocupar com todos os detalhes envolvidos.

¨ Implementar o projeto obtido.

n Possibilita uma melhor seleção e definição de objetos.

Visão Tradicional x Nova Visão da OO

n

É mais fácil pensar em termos de

responsabilidades, uma vez que isso ajuda a definir a interface pública dos objetos.

n

Se um objeto tem uma responsabilidade, deve

n

Se um objeto tem uma responsabilidade, deve haver um meio de pedir a ele para cumprir com sua responsabilidade.

n

Entretanto, isso nada implica, no que diz respeito ao que está dentro do objeto. A informação pela qual ele é responsável pode nem mesmo estar dentro do próprio objeto.

Visão Tradicional x Nova Visão da OO

“Focar em motivação em vez de implementação é um tema recorrente implementação é um tema recorrente

em padrões de projeto.”

Encapsulamento : Nova Visão

n

O encapsulamento não existe apenas para esconder dados (visão limitada);

O encapsulamento deve ser pensado como qualquer

n

O encapsulamento deve ser pensado como qualquer tipo de ocultação. Pode-se não só ocultar dados, mas também implementações, classes derivadas, ou

qualquer coisa.

(7)

Encapsulamentos : Exemplo

Partimos do exemplo do padrão Adapter:

n Encapsulamento de dados: os dados das classes derivadas estão escondidos de tudo o mais

n Encapsulamento de métodos;

n Encapsulamento de subclasses: clientes de Figura não enxergam Pontos, Linhas, Quadrados, etc..

n Encapsulamento de outros objetos: nada além de Círculo tem conhecimento de CírculoXX.

Encapsulamentos : Exemplo

n

Um encapsulamento é assim obtido quando existe uma classe abstrata que se comporta

polimorficamente, sem o cliente dela conhecer que tipo de classe derivada realmente está presente.

tipo de classe derivada realmente está presente.

¨ Vantagem: possibilita uma maneira melhor de dividir (decompor) os programas.

n

As camadas encapsuladas se tornam as interfaces que se projeta.

¨ No Exemplo: encapsulando tipos diferentes de Figuras, pode-se adicionar outras novas sem mudar qualquer um dos programas cliente que as utilizam.

Descubra o que está variando e encapsule!

n

“Considere o que deve ser variável em seu projeto”.

GoF

n

Muitos padrões de projeto utilizam encapsulamento para criar camadas entre objetos, possibilitando ao para criar camadas entre objetos, possibilitando ao projetista mudar coisas em lados diferentes das camadas sem afetar o outro lado ⇒ Fraco Acoplamento.

Singleton

Objetivo:

n "Garantir que uma classe só tenha uma única instância, e prover um ponto de acesso global a ela." [GoF]

e prover um ponto de acesso global a ela." [GoF]

(8)

Singleton

n

Garantir que apenas um objeto exista, independente do número de requisições que receber para criá-lo

n

Aplicações

¨ Um único banco de dados

¨ Um único acesso ao arquivo de log

¨ Um único objeto que representa um vídeo

¨ Uma única fachada (Façade pattern)

n

Objetivo: garantir que uma classe sótenha uma instância

Singleton - Implementação

n

Singleton funciona tendo um método especial usado para instanciar o objeto desejado.

¨ Ao ser chamado, esse método confere se o objeto já foi instanciado. No caso de tê-lo sido, o método

simplesmente retorna uma referência a ele; senão, simplesmente retorna uma referência a ele; senão, instancia o objeto e retorna uma referência para a nova instância.

¨ Para assegurar que esse seja o único meio de

instanciar um objeto desse tipo, defino o construtor de tal classe como protegido ou privativo.

Singleton - Estrutura Template Method

Objetivo:

n "Definir o esqueleto de um algoritmo dentro de uma operação, deixando alguns passos a serem operação, deixando alguns passos a serem preenchidos pelas subclasses. Template Method permite que suas subclasses redefinam certos passos de um algoritmo sem mudar sua estrutura." [GoF]

(9)

Template Method - Solução

n

O que éum TemplateMethod

¨ Um Template Method define um algoritmo em termos de operações abstratas que subclasses sobrepõem para operações abstratas que subclasses sobrepõem para oferecer comportamento concreto

n

Quando usar?

¨ Quando a estrutura fixa de um algoritmo puder ser definida pela superclasse deixando certas partes para serem preenchidos por implementações que podem variar

Template Method -

Exemplo

Template Method – Estudo de Casos

Type

TFuncionario = class private

nome : string;

salarioBruto : real;

dependentes : integer;

public

constructor create (n : string, s : real, d : integer);

procedure exibir;

// através de um showmessage, exibe as informações do objeto

function calcularSalario(perc: integer): real;

protected

function calcularImposto: real; abstract; virtual;

function calcularSalarioFamilia: real; abstract; virtual;

end;

Template Method – Estudo de Casos

function calcularSalario(perc: integer): real;

Var salario : real;

begin

salario := salarioBruto * ( 1 + perc/100);

salario := salario –calcularImposto;

salario := salario –calcularSalarioFamilia;

result := salario;

end;

(10)

Template Method – Estudo de Casos

Type

TAtendente = class (TFuncionario)

public

protected

function calcularImposto: real;

// corresponde a 12,5% do salario bruto

function calcularSalarioFamilia: real;

// corresponde a 11% do salario para cada dependente end;

Template Method – Estudo de Casos

Type

TGerente = class (TFuncionario)

public

protected

function calcularImposto: real;

// corresponde a 27,5% do salario bruto + 3% para cada dependente

function calcularSalarioFamilia: real;

// corresponde a 5% do salário para cada dependente end;

Template Method – Estudo de Casos

n

Na unit principal de sua aplicação:

1. crie um objeto Gerente.

2. aplique um aumento de salário mediante um percentual dado, exibindo as suas informações (inclusive o salário líquido).

3. crie um objeto Atendente.

4. faça da mesma forma que o Gerente (item 2).

Método Fábrica Factory Method

Objetivo:

n Definir uma interface para criar um objeto mas deixar que subclasses decidam que classe instanciar. Factory que subclasses decidam que classe instanciar. Factory Method permite que uma classe delegue a

responsabilidade de instanciamento às subclasses."

[GoF]

(11)

Factory Method -

Implementação

1. É possível criar um objeto sem ter conhecimento algum de sua classe concreta?

2. Esse conhecimento deve estar em alguma parte do sistema, mas não precisa estar no cliente

3. FactoryMethod define uma interface comum para criar objetos

criar objetos

4. O objeto específico é determinado nas diferentes implementações dessa interface

5. O cliente do Factory Method precisa saber sobre implementações concretas do objeto criador do produto desejado

Factory Method -

Exemplo

Fábrica Abstrata Abstract Factory

Objetivo:

n prover uma interface para criação de famílias de objetos relacionados sem especificar sua classe concreta.

relacionados sem especificar sua classe concreta.

n Algumas vezes, diversos objetos necessitam ser instanciados de uma forma coordenada.

n O padrão Abstract Factory garante que o sistema sempre obtenha os objetos corretos para cada situação.

Abstract Factory

- Motivação

n Considere uma aplicação com interface gráfica que é implementada para plataformas diferentes (Motif para UNIX e outros ambientes para Windows e MacOS).

n As classes implementando os elementos gráficos não podem ser definidas estaticamente no código. Precisamos de uma implementação diferente para cada ambiente. Até em um mesmo ambiente, gostaríamos de dar a opção ao usuário de implementar diferentes aparências (look- and-feels).

and-feels).

n Podemos solucionar este problema definindo uma classe abstrata para cada elemento gráfico e utilizando diferentes implementações para cada aparência ou para cada ambiente.

n Ao invés de criarmos as classes concretas com o operador new, utilizamos uma Fábrica Abstrata para criar os objetos em tempo de execução.

n O código cliente não sabe qual classe concreta utilizamos.

(12)

Abstract Factory -

Aplicabilidade

Use uma fábrica abstrata quando:

n

um sistema deve ser independente da forma como seus produtos são criados e representados;

n

um sistema deve poder lidar com uma família de

n

um sistema deve poder lidar com uma família de vários produtos diferentes;

n

você quer prover uma biblioteca de classes de produtos mas não quer revelar as suas

implementações, quer revelar apenas suas interfaces.

Estrutura

AbstractProductA

ProductA1

Client

ProductA2 AbstractFactory

CreatProductA() CreatProductB()

ProductA1 ProductA2

ConcreteFactory2

CreatProductA() CreatProductB() ConcreteFactory1

CreatProductA() CreatProductB()

AbstractProductB

ProductB1 ProductB2

Colaborações

n Normalmente, apenas uma instância de

ConcreteFactory é criada em tempo de execução.

n Esta instância cria objetos através das classes

ConcreteProduct correspondentes a uma família de ConcreteProduct correspondentes a uma família de produtos.

n Uma AbstractFactory deixa a criação de objetos para as suas subclasses ConcreteFactory.

Conseqüências

O padrão

1. isola as classes concretas dos clientes;

2. facilita a troca de famílias de produtos

(basta trocar uma linha do código pois a criação da fábrica concreta aparece em um único ponto do programa);

concreta aparece em um único ponto do programa);

3. promove a consistência de produtos

(não há o perigo de misturar objetos de famílias diferentes);

4. dificulta a criação de novos produtos

ligeiramente diferentes

(pois temos que modificar

a fábrica abstrata e todas as fábricas concretas).

(13)

Implementação

1. Na fábrica abstrata, cria-se um método fábrica para cada tipo de produto. Cada fábrica concreta implementa o código que cria os objetos de fato.

2. Se tivermos muitas famílias de produtos, teríamos um excesso de classes “fábricas concretas”.

Para resolver este problema, podemos usar o Prototype:

criamos um dicionário mapeando tipos de produtos em instâncias prototípicas destes produtos.

Então, sempre que precisarmos criar um novo produto pedimos à sua instância prototípica que crie um clone (usando um método como clone() ou copy()).

Implementação

Ca rro val or : Doubl e getValor()

Vectra

Vectra()

Omega

Om ega()

Golf

Golf()

Gol

Gol()

Definindo as classes concretas sobre Carros

Implementação

Carro val or : D oubl e

Fa ctoryEx am ple main()

Ca rroFactory Carro getCarro()

Definindo uma Fábrica val or : D oubl e ge tVal or()

Vectra Vectra()

Om ega Om ega()

Golf Golf()

Gol Gol()

Definindo uma Fábrica de Carros

Implementação

Fabricante No me : Stri ng Ca rro getCarro

Chevrolet

Chevrolet() Carro getCarro()

Volkswagen

Volks wagen() Carro getCarro ()

Decompondo as Fábricas de Carros

(14)

Implementação

Fa bricante Nom e : String Carro getCar ro

Chevrole t

Chevrolet() Carro getCarro()

Volksw agen

Volks wagen( ) Carro ge tC ar ro( ) Abstra ctFa ctoryEx ample

void main()

Carro getCarro() Carro ge tC ar ro( )

Carro v al or : Do ubl e g etV alo r()

Ve c tra

Vectra() Om ega

Om ega()

Golf Golf()

Gol Gol()

Aplicando Fábrica Abstrata

n O objeto cliente sabe apenas a quem solicitar os objetos de que necessita e como usá-los;

n A classe Abstract Factory especifica quais objetos podem ser instanciados definindo um método para cada um desses tipos diferentes de objetos.

diferentes de objetos.

¨ Tipicamente um objeto A.F. terá um método para cada tipo de objeto que deve ser instanciado.

n As fábricas concretas especificam quais objetos devem ser instanciados.

- Notas Práticas

n O objeto cliente não sabe de quais implementações concretas particulares dos objetos servidores ele dispõe porque o objeto fábrica tem a responsabilidade e criá-los.

n O objeto cliente nem mesmo tem conhecimento de que fábrica específica utiliza, uma vez que somente sabe que fábrica específica utiliza, uma vez que somente sabe que dispõe de um objeto Abstract Factory.

n Esconde-se (encapsula) do Cliente a escolha sobre quais objetos servidores estão sendo usados. Em razão de o Cliente não ser afetado, isso facilitará no futuro proceder mudanças no algoritmo para a realização dessa escolha.

- Notas Práticas

n O Abstract Factory fornece um novo tipo de decomposição:

por responsabilidade. Utiliza-lo decompõe nosso problema em:

¨ Quem está usando nossos objetos

¨ Quem está decidindo quais objetos particulares usar.

n O uso do A.F. é indicado quando o domínio do problema tem presentes famílias distintas de objetos, sendo cada família usada sob diferentes circunstâncias.

(15)

Usos Conhecidos

n InterViews usa fábricas abstratas para encapsular diferentes tipos de aparências para sua interface gráfica

n ET++ usa fábricas abstratas para permitir a fácil portabilidade para diferentes ambientes de janelas (XWindows e SunView, por exemplo)

n Sistema de captura e reprodução de vídeo feito na UIUC usa fábricas abstratas para permitir portabilidade entre diferentes placas de captura de vídeo.

n Em linguagens dinâmicas como Smalltalk (e talvez em POO em geral) classes podem ser vistas como fábricas de objetos.

Padrões Relacionados

n Fábricas abstratas são normalmente implementadas com métodos fábrica (FactoryMethod(107)) mas podem também ser implementados usando Prototype(117).

n O uso de protótipos é particularmente importante em linguagens não dinâmicas como C++ e em linguagens linguagens não dinâmicas como C++ e em linguagens

"semi-dinâmicas" como Java.

n Em Smalltalk, não é tão relevante.

¨ Curiosidade: a linguagem Self não possui classes, toda criação de objetos é feita via clonagem.

n Uma fábrica concreta é normalmente um Singleton(127)

Strategy

Objetivo:

n "Definir uma família de algoritmos, encapsular cada um, e fazê-los intercambiáveis. Strategy permite que e fazê-los intercambiáveis. Strategy permite que algoritmos mudem independentemente entre clientes que os utilizam." [GoF]

Strategy - Princípios

n

Os objetos tem responsabilidades

n

As implementações diferentes, específicas dessas responsabilidades, são realizadas mediante o uso de polimorfismo

polimorfismo

n

Existe uma necessidade de gerenciar diferentes implementações do que é, conceitualmente, o mesmo algoritmo

n

Constitui uma boa prática de projeto separar um

comportamento de outro que ocorra no domínio do

problema.

(16)

Strategy – requisitos novos

n Há uma resistência no desenvolvimento de se lidar com questões a longo prazo.

n Há uma crença de que, se projetar para mudanças é muito mais caro do que projetar sem considerá-las.

Estudo de casos:

n Estudo de casos:

¨ Consideremos o modo como os sistemas podem mudar

¨ Estaremos antecipando o fato de que mudanças ocorrerão e sabendo onde de fato elas ocorrerão.

n Segundo a GoF:

¨ Programar para uma interface, não para uma implementação

¨ Favorecer composição de objetos sobre herança de classe

¨ Considerar o que deverá ser variável em seu projeto

Strategy – Exemplo

n Sistema de E-Commerce para vendas nos EUA.

n Classe ControladorVendas: identifica quando um pedido está sendo realizado e o passa ao objetoPedidoVenda.

n Classe PedidoVenda:

¨ Possibilita o preenchimento do pedido por meio de uma inteface gráfica.

¨ Fazer cálculos de impostos.

¨ Processar o pedido. Imprimir um recibo de venda.

Strategy – Exemplo

n

Novos requisitos:

¨ Mudar a maneira de se lidar com impostos : calcular impostos de fora dos EUA

¨ Para o Canadá, poderíamos realizar uma derivação:

Strategy – Exemplo

n

Regras de taxação estão variando

→

Encapsular

(17)

Strategy – Exemplo

n

Utilizamos composição em vez de herança

¨ Ao invés de se realizar versões diferentes de pedidos de vendas (usando herança), incluiremos a variação com composição.

Strategy – Análise da solução

n

Coesão aprimorada:

¨ O imposto é tratado em sua própria classe.

¨ Novos requisitos sendo obtidos sobre Impostos, precisamos

simplesmente derivar uma nova classe, a partir de CalcImposto, que os implemente.

os implemente.

n Torna-se mais fácil deslocar responsabilidades. Permite à regra de negócio variar independentemente do objeto PedidoVenda que se utiliza.

Strategy – Quando Usar

n Quando classes relacionadas forem diferentes apenas no seu comportamento

¨ Strategy oferece um meio para configurar a classe com um entre vários comportamentos

n Quando você precisar de diferentes variações de um

n Quando você precisar de diferentes variações de um mesmo algoritmo

n Quando um algoritmo usa dados que o cliente não deve conhecer

n Quando uma classe define muitos comportamentos, e estes aparecem como múltiplas declarações

condicionais em suas operações

¨ Stategy permite implementar as operações usando polimorfismo

Observer

Objetivo:

n "Definir uma dependência um-para-muitos entre objetos para que quando um objeto mudar de estado, todos os para que quando um objeto mudar de estado, todos os seus dependentes sejam notificados e atualizados automaticamente." [GoF]

¨ Há, portanto, um conjunto de objetos que precisam ser notificados sempre que um evento ocorre.

¨ A notificação deve ser automática

¨ Entretanto, não se deseja mudar o objeto de divulgação toda vez que exista uma mudança no conjunto de objetos que atenda a notificação > pretende- se desacoplar os notificadores e os notificados.

(18)

Observer Observer

n

Como garantir que objetos que dependem de outro objeto fiquem em dia com mudanças naquele objeto?

¨ Como fazer com que os observadores tomem conhecimento do objeto de interesse?

Como fazer com que o objeto de interesse atualize os

¨ Como fazer com que o objeto de interesse atualize os observadores quando seu estado mudar?

n

Possíveis riscos

¨ Relacionamento (bidirecional) implica alto acoplamento.

¨ Como podemos eliminar o relacionamento bidirecional?

Observer - Exemplo Observer - Exemplo

n

Novo requisito: sempre que um novo cliente entrar no sistema:

¨ Enviar mensagem eletrônica para o cliente.

¨ Verificar o endereço do cliente junto ao correio.Verificar o endereço do cliente junto ao correio.

n

Os requisitos estão completos? As coisas mudarão no futuro?

¨ Caso se esteja certo, pode-se implementar esse comportamento na própria classe Cliente.

¨ Mas requisitos sempre mudam. Outro requisito irá exigir uma outra mudança no comportamento do Cliente.

(19)

Observer - Aplicação

PASSO 1: fazer os observadores se comportarem da mesma maneira.

n Analisando o problema:

¨ Há diferentes tipos de objetos

¨ Interfaces diferentes.

n Primeiro, devo identificar todos os objetos que desejam ser notificados. Serão chamados de observadores, pois estão esperando que um evento ocorra.

n Pretende-se que todos eles tenham a mesma interface; do contrário, terei que modificar o sujeito(o objeto que está disparando o evento, por exemplo, Cliente) para lidar com cada tipo de observador.

Observer - Aplicação

PASSO 2: fazer os observadores se registrarem PASSO 2: fazer os observadores se registrarem

n Deseja-se que os observadores sejam responsáveis por saber o que devem observar e que o sujeito não necessite conhecer quais observadores dependem dele.

quais observadores dependem dele.

n Precisa-se encontrar uma maneira de os observadores

registrarem-se com o sujeito. Como todos são do mesmo tipo, deve-se adicionar ao sujeito dois métodos:

¨ Anexar(Observer): adiciona o observador fornecido à sua lista de observadores

¨ Desanexar(Observer): remove-lo da lista

Observer - Aplicação

n

n PASSO 3: notificar os observadores quando o evento PASSO 3: notificar os observadores quando o evento ocorre

ocorre

n Com Observers do Sujeito registrados, necessitamos notificar

n Com Observers do Sujeito registrados, necessitamos notificar os Observers de quando ocorre o evento:

¨ Cada Observer implementa um método denominado atualizar_.

¨ O Sujeito, por sua parte, implementa um método notificar_, que varre sua lista de Observers, e o chama para cada um deles.

¨ Esse método deve conter o código para lidar com o evento.

(20)

Observer - Aplicação

n

n PASSO 4: obter informação a partir do sujeitoPASSO 4: obter informação a partir do sujeito

n

Notificar os observadores não é suficiente.

n

Deve-se também adicionar método(s) ao sujeito que

n

Deve-se também adicionar método(s) ao sujeito que possibilite(m) aos observadores obter qual seja a informação de que necessitem.

¨ Os Observers se anexam à classe Cliente quando são instanciados. Se necessitam de mais informação do sujeito (Cliente), o método atualizar deve passar uma referência ao objeto que o chamou.

¨ Quando um novo Cliente é adicionado, o método notificar chama esses Observers

Observer - Aplicação

n Cada Observer chama obterEstado para informar-se a respeito do Cliente recentemente adicionado, objetivando verificar o que ele necessita fazer.

n Nesse caso, usamos métodos de classe (static) para anexar e

n Nesse caso, usamos métodos de classe (static) para anexar e desanexar, visto que os observadores desejam ser notificados por todos os novos Clientes. A eles é passada a referência ao Clientecriado.

n Esse enfoque permite adicionar novos Observers sem afetar quaisquer classes existentes.

Observer – Notas Práticas

n O padrão Observer não serve para ser utilizado toda vez que houver uma dependência entre os objetos. Exemplo:

¨ Sistema de processamento de notas e vendas:

¨ Um objeto Imposto, quando itens são adicionados à nota, esse objeto deve ser notificado, de modo que o imposto possa ser recalculado.

ser recalculado.

¨ Tal notificação é conhecida de início e outras provavelmente não serão adicionados >> NÃO É UMA BOA SITUAÇÃO PARA O PADRÃO OBSERVER (adiciona mais complexidade).

n Se a lista dos objetos que precisam ser notificados de um evento muda, ou de alguma forma é condicional, o padrão Observer tem maior valor.

n Pode também ser útil se o sistema for executado sob

condições diferentes ou por clientes diferentes, cada um tendo uma lista diferente de observadores requeridos.

Observer – Prós e Contras

n

Vantagens

¨ Tanto observadores quando sujeitos observados podem ser

reutilizados e ter sua interface e implementação alteradas sem afetar o sistema

¨ O acoplamento forte implicado pelo relacionamento bidirecional é

¨ O acoplamento forte implicado pelo relacionamento bidirecional é reduzido com o uso de interfaces e classes abstratas

n

Desvantagens

¨ O abuso pode causar sério impacto na performance.

¨ Sistemas onde todos notificam todos a cada mudança ficam inundados de requisições ("tempestade de eventos")

(21)

Façade – Uso de encapsulamento

n

Façade pode também ser utilizado para

esconder ou encapsular o sistema. O sistema ficaria ligado à classe Façade, mas sem estar sendo apresentado aos usuários.

sendo apresentado aos usuários.

n

Razões:

¨ Uso de sistema de rastreamento

¨ Troca de sistemas.

Façade (Fachada)

n

Façade em francês significa fachada, por exemplo, fachada de um prédio. Quando olhamos para um prédio, apenas conseguimos ver a sua fachada, ignorando completamente o que está na parte de ignorando completamente o que está na parte de dentro.

n

O objetivo deste padrão é diminuir o acoplamento e a dependência entre classes. O façade fornece uma interface única e simplificada para o funcionamento do subsistema.

Façade (Fachada)

n

Este padrão é usado quando se deseja uma interface simples para um subsistema complexo ou para separar o subsistema em camadas.

n

O padrão pode tornar a tarefa de acessar um grande

n

O padrão pode tornar a tarefa de acessar um grande número de classes mais simples ao fornecer uma camada adicional de interface. Ao usar este padrão simplificamos em muito o código complexo ao usar muitas interfaces. Fazemos isto ao criar uma única classe, Façade, para acessar essas interfaces.

Façade (Fachada)

(22)

Façade (Fachada) Façade – Quando Usar

n

Sempre que for desejável criar uma interface para um conjunto de objetos com o objetivo de

facilitar o uso da aplicação

¨ Permite que objetos individuais cuidem de uma única tarefa, deixando que a fachada se encarregue de divulgar as suas deixando que a fachada se encarregue de divulgar as suas operações

n

Fachadas viabilizam a separação em camadas com alto grau de desacoplamento

n

Existem em várias partes da aplicação

¨ Fachada da aplicação para interface do usuário

¨ Fachada para sistema de persistência: Data Access Object

Façade – Nivel de acoplamento

n

Fachadas podem oferecer maior ou menor isolamento entre aplicação cliente e objetos

¨ Nível ideal deve ser determinado pelo nível de acoplamento desejado entre os sistemas

n

A fachada mostrada como exemplo isola totalmente o cliente dos objetos

n

Outra versão com menor isolamento (requer que aplicação-cliente conheça objeto Cliente)

Facade f; // Obtem instancia f f.registrar("Zé", 123);