Padrões de Projeto de Software Aula 04

Prévia do material em texto

AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
PADRÕES DE CRIAÇÃO 
CREATIONAL PATTERNS 
 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
Padrões de criação 
• Abstraem o processo de instanciação 
• Tornam um sistema independente da forma como os 
objetos são criados, compostos e representados. 
 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
Padrões Criacionais (5) 
1. Abstract Factory 
2. Builder 
3. Factory Method 
4. Prototype 
5. Singleton 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
1. Abstract Factory (Fábrica Abstrata) 
• Objetivo: 
 prover uma interface para criação de famílias de 
objetos relacionados sem especificar sua classe 
concreta. 
• Motivação: 
 Considere uma aplicação com interface gráfica 
que é implementada para plataformas diferentes 
(Motif para UNIX e outros ambientes para 
Windows e MacOS). 
 ... 
 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
1. Abstract Factory - Motivação 
• As classes que implementam 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). 
• 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. 
• 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. 
• O código cliente não sabe qual classe concreta utilizamos. 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
1. Abstract Factory 
Use uma fábrica abstrata quando: 
• O sistema precisa ser independente de como os produtos 
são criados, compostos e representados. 
• O sistema deve ser configurado com uma de múltiplas 
famílias de produtos. 
• Produtos de uma família devem ser sempre utilizados em 
conjunto e isto precisa ser garantido. 
• Deseja-se disponibilizar uma biblioteca de classes de 
produtos, mas revelar somente as suas interfaces, não suas 
implementações. 
Aplicabilidade: 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
1. Abstract Factory - Estrutura 
Client AbstractFactory 
CreatProductA() 
CreatProductB() AbstractProductA 
ProductA1 ProductA2 
ConcreteFactory2 
CreatProductA() 
CreatProductB() 
ConcreteFactory1 
CreatProductA() 
CreatProductB() 
AbstractProductB 
ProductB1 ProductB2 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
2. Builder 
• Objetivo: 
• Separar a construção de um objeto complexo de sua 
representação para que o mesmo processo de 
construção possa criar representações diferentes. 
• Mover a lógica de construção de uma classe para um 
objeto externo, a fim de reduzir a complexidade da 
mesma e permitir a construção gradual de objetos-
alvo a partir dessa classe. 
• Motivação: 
• Suponha que se deseje converter documentos RTF 
para outros formatos (texto, HTML, ...) 
• Seria necessário verificar quais partes um documento 
pode ter e definir uma especialização para cada uma 
das partes 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
2. Builder 
Estrutura: 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
2. Builder 
Motivação: 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
2. Builder 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
2. Builder 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
2. Builder 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
2. Builder 
Aplicabilidade: 
• Builder permite que uma classe se preocupe com apenas 
uma parte da construção de um objeto. É útil em algoritmos 
de construção complexos. 
• Use-o quando o algoritmo para criar um objeto 
complexo precisar ser independente das partes que 
compõem o objeto e da forma como o objeto é 
construído. 
• Builder também suporta substituição dos construtores, 
permitindo que a mesma interface seja usada para 
construir representações diferentes dos mesmos dados. 
• Use quando o processo de construção precisar suportar 
representações diferentes do objeto que está sendo 
construído. 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
3. Factory Method 
• Objetivo: 
• Definir uma interface de criação de objetos mas 
deixar as subclasses decidirem qual objeto criar 
• Motivação: 
• Na construção de frameworks, não é possível, a 
priori, determinar qual elemento deve ser criado 
• A solução é permitir que o instanciador do 
framework faça a criação de uma instância 
específica 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
3. Factory Method 
Estrutura 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
3. Factory Method 
• Aplicabilidade: 
• Sugestões para o uso desse padrão (GAMMA, HELM, 
et al., 2000): 
1. Quando uma classe não pode antecipar ou 
conhecer a classe dos objetos que deve criar; 
2. Quando uma classe quer suas subclasses para 
especificar os objetos que cria; 
3. Quando classes delegam responsabilidade à 
alguma das várias subclasses ajudantes, e deseja-
se localizar qual é a subclasse ajudante acessada. 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
3. Factory Method 
• Exemplo: 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
4. Prototype 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
4. Prototype 
• Objetivo: 
• Especificar tipos de objetos a serem criados 
usando protótipos e aplicando clonagem nesses 
protótipos 
• Motivação: 
• Existem situações onde é desejável utilizar um 
objeto modelo complexo para a criação de outros 
objetos 
• Supondo o caso de uma ferramenta de desenho, 
pode ser útil criar estruturas complexas e fazer 
uso delas como base para outros desenhos mais 
complexos 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
4. Prototype 
• Estrutura: 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
4. Prototype 
Aplicabilidade: 
• O padrão Prototype pode ser utilizado em sistemas que 
precisam ser independentes da forma como os seus 
componentes são criados, compostos e representados. O 
padrão Prototype pode ser útil em sistemas com as 
seguintes características: 
• Sistemas que utilizam classes definidas em tempo de 
execução; 
• Sistemas que utilizam o padrão Abstract Factory para 
criação de objetos. Neste caso, a hierarquia de classes 
pode se tornar muito complexa e o padrão Prototype 
pode ser uma alternativa mais simples, por realizar a 
mesma tarefa com um número reduzido de classes; 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
4. Prototype 
Exemplo: 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com5. Singleton 
• Objetivo: 
• Assegurar que uma determinada classe tem 
somente uma única instância e fornecer um ponto 
global de acesso a ela 
• Motivação: 
 Garantir que exista um determinado número X de 
objetos de uma classe 
• Independentemente do número de requisições 
que receber para criá-lo 
 Exemplos de aplicação 
• Único banco de dados 
• Único acesso ao arquivo de log 
• Única fachada (padrão Façade) 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
5. Singleton 
• Propósito 
• Assegurar o controle da quantidade de instâncias da 
classe 
• Ponto de acesso global a ela 
• Aplicabilidade 
• Exatamente uma instância da classe 
• Acessível pelos clientes de ponto de acesso bem 
conhecido 
• Instância única deve ser extensível através de 
subclasses 
• Clientes capazes de usar instância estendida 
sem alterar seu código 
 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
5. Singleton 
• Estrutura 
 
 
 
 
 
• Participantes 
• Singleton 
• Define operação Instance que permite que 
clientes acessem instância única 
• Instance é operação de classe 
• Pode ser responsável pela criação de sua única 
instância 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
5. Singleton 
• Consequências 
• Acesso controlado a instância única 
• Espaço de nomes reduzido 
• Refinamento de operações e representação 
• Não há número variado de instâncias 
• Mais flexível do que operações de classes 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
5. Singleton 
Exemplo: 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
5. Singleton 
Exemplo: 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
5. Singleton 
Exemplo: 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
Exercícios – Padrões Criacionais 
1. Implemente uma aplicação que constrói Figuras: (Use uma abstract 
Factory para controlar a criação de todos os objetos) 
• Pontos (x, y) 
• Circulos (Ponto, raio) 
• Retangulos (Ponto, Ponto) 
 
2. Uma aplicação precisa construir objetos Pessoa e Empresa. Para isto, 
precisa ler dados de um banco para cada produto. 
1. Para construir uma Pessoa é preciso obter nome e identidade. Apenas 
se os dois forem lidos a pessoa pode ser criada. 
2. Para construir uma empresa é preciso ler o nome e identidade do 
responsável e depois construir a pessoa do responsável. 
 
3. Utilize a fachada Figura, onde os construtores são guardados, e um 
método estático que seleciona o construtor desejado com uma chave. 
 
Figura!!! 
AULA 4 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
Exercícios – Padrões Criacionais 
 
 
 
 
4. Elabore um programa para exercitar a criação do padrão Prototype: 
• O Cliente é um revendedor de automóveis VW. 
• O (Abstract) Prototype é um modelo de automóvel GOL. 
• Os ConcretePrototype são modelos de Automóveis GOL. 
• Modelo Luxo. 
• Gol com Motor AP de 250HP e Pneus 13/185. 
• Modelo Standard. 
• Gol com Motor AP de 180HP e Pneus 13/185 
• Crie uma aplicação de venda de automóveis que “vende” Gol através da 
clonagem dos modelos Luxo e Standard 
5. Usando o padrão singleton implemente uma conexão a um banco de dados.