Padrões de Criação: Factory Method e Singleton

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

*
*
*
*
AULA 4
PADRÕES DE CRIAÇÃO
*
*
FACTORY METHOD
*
*
FACTORY METHOD
Temos uma interface para o produto final 
Outra interface que se responsabiliza pela produção/instanciação/criação do objeto que é o produto final
A classe fábrica concreta é quem cria os objetos produtos concretos os quais implementam ou estendem as suas devidas interfaces
*
*
FACTORY METHOD
Conceito: É uma interface para instanciação de objetos que mantém isoladas as classes concretas usadas da requisição da criação destes objetos.
Categoria: padrão de criação
Aplicabilidade: Nos momentos em que temos uma classe que não pode antecipar a classe a ser criada; quado temos uma classe e desejamos que suas subclasses especifiquem os objetos que criam.
Estrutura: Product = a interface de objetos que o método fabrica (documento). (OBS: interface, no conceito de Design Patterns, significa um modelo bem definido de uma abstração, podendo ser uma classe abstrata ou a própria interface do Java)
ConcreteProduct = a implementação da interface de produtos (meu documento).
Creator = a declaração do método fábrica, que retorna um objeto do tipo Product (aplicação).
*
*
FACTORY METHOD
O padrão Factory Method possui a seguinte intenção:
“Definir uma interface para criar um objeto, mas deixar as subclasses decidirem que classe instanciar. O Factory Method permite adiar a instanciação para subclasses.”
Ou seja, ao invés de criar objetos diretamente em uma classe concreta, nós definimos uma interface de criação de objetos e cada subclasse fica responsável por criar seus objetos. Seria como se, ao invés de ter uma fábrica de carros, nós tivéssemos uma fábrica da Fiat, que cria o carro da Fiat, uma fábrica da Ford, que cria o carro da Ford e etc.
*
*
FACTORY METHOD
*
*
FACTORY METHOD
CRIAÇÃO DO CÓDIGO fábricas fiat, gol etc;
Exercício : criar fábrica para veículos e criar os veículos : Carro , caminhão, Moto; 
*
*
*
*
SINGLETON
O padrão de projeto (Design Pattern) Singleton tem entre outras funções a garantia de apenas uma instância de determinada classe, ou seja, somente um objeto por classe.  Para o desenvolvimento de tal implementação existem algumas maneiras, mas a tradicional é baseada no uso de atributos estáticos e da modificação do controle de acesso do construtor, onde um membro externo depende de uma propriedade para “requisitar” uma instância.
*
*
SINGLETON
*
*
SINGLETON
Classe Singleton
Considerando as características temos:
1)      Variável estática contendo a instância para a classe;
2)      Construtor declarado private.
3)      Método para requisitar instância.
A implementação em Java seria a seguinte:
public class PadraoSingleton{
	private static PadraoSingleton padraoSingleton;
	private PadraoSingleton(){}
 
	public static PadraoSingleton getInstance(){
		if (padraoSingleton == null){
			padraoSingleton = new PadraoSingleton();
		}
	return padraoSingleton;
	}
}
Singleton na Prática
O uso do padrão Singleton, normalmente está associado a economia de recursos, ou melhor, quando a resposta para seguinte pergunta é verdadeira:
Quando você precisa de uma única instância?
*
*
SINGLETON
Por exemplo, quando múltiplas instâncias não fazem sentido, quando estas instâncias apenas desperdiçam memória ou processamento. Na pior das hipóteses, quando múltiplas instâncias causam um comportamento incorreto para o software. Desta forma também garante um ponto de acesso global para acesso a instância.
Considerando o escopo de vida do Singleton, o mesmo é iniciado na primeira requisição e finalizando apenas quando a aplicação é encerrada. O que pode considerar uma longa vida caso o mesmo seja usado somente uma vez, assim o uso do mesmo deve ter uso considerado sem esquecer que o escopo do mesmo é de todo um programa, um sistema ou mesmo um sistema distribuído.
Este padrão tem um uso comum em conexões com banco de dados, pois o mesmo proporciona uma única instância, ou seja, canal de comunicação entre a aplicação e o SGBD. 
Reconsiderando o uso do Singleton em implementações de Classes de conexão com banco de dados, não se pode esquecer que a sobrecarga de execução das sintaxes será toda sobre uma única thread, o que pode ocasionar outros problemas à aplicação.
*
*
SINGLETON
O padrão Singleton em resumo proporciona uma única instância e fornece um ponto global de acesso a mesma..
O Singleton é um dos padrões de projeto mais simples. Ele é usado quando for necessária a existência de apenas uma instância de uma classe. Foi apresentado no GoF como um padrão de criação, por lidar com a criação de objetos.
Segundo o GoF para uma classe ser um singleton, deve-se garantir que haverá apenas uma instância na aplicação e que deve-se fornecer um ponto de acesso à mesma. Mas como garantir que haverá apenas uma instância? É de conhecimento comum que, para criar uma instância de uma classe, devemos chamar o seu construtor. Assim, para resolvermos o problema, devemos restringir o acesso ao construtor, tornando-o um método privado. Em seguida, deve-se utilizar um método público que faça o controle da instanciação, de modo que ela só possa ser feita uma vez. 
*
*
SINGLETON
EXEMPLO SINGLETON CONEXÃO BANCO DE DADOS
*
*
CLASSE USUÁRIO
*
*
CAMADA DE PERSISTÊNCIA
*
*
EXERCÍCIO
Criar duas classes de Modelo : Cliente e Produto , suas respectivas Telas de cadastro(JInternalFrame) utilizando o padrão SINGLETON, uma classe Desktop do tipo JFrame
*
*
*
*
*
*
*
*
*
*
PADRÕES DE CRIAÇÃO
BUILDER
*
*
BUILDER
A intenção do padrão:
“Separar a construção de um objeto complexo de sua representação de modo que o mesmo processo de construção possa criar diferentes representações.”
Separar a construção da representação segue a mesma ideia dos padrões Factory Method e Abstract Factory. No entanto o padrão Builder permite separar os passos de construção de um objeto em pequenos métodos.
No padrão Builder temos também uma interface comum para todos os objetos que constroem outros objetos. Essa interface Builder define todos os passos necessários para construir um objeto.
*
*
BUILDER
*
*
BUILDER
DIRECTOR — constrói um objeto utilizando a interface do builder;
BUILDER — especifica uma interface para um construtor de partes do objeto-produto;
CONCRETE BUILDER — define uma implementação da interface builder, mantém a representação que cria e fornece interface para recuperação do produto;
PRODUCT — o objeto complexo acabado de construir. Inclui classes que definem as partes constituintes.
*
*
BUILDER
Cada fábrica do Builder vai personalizar o seu Produto nos pequenos passos de construção. Essa diferença fica mais evidente ao comparar os diagramas UML do Facottory Method, Abstract Factory e BulIder. A estrutura do Builder é bem menor que a dos outros dois.
Outra diferença é que o Builder foca na divisão de responsabilidades na construção do Produto. Enquanto nos padrões Abstract Factory e Factroy Method tínhamos apenas o método criarCarro(), que deveriam executar todo o processo de criação e devolver o produto final, no padrão Builder nós definimos quais os passos devem ser executados (na classe Builder) e como eles devem ser executados (na classe Director).
Várias classes Director também podem reutilizar classes Builder. Como o Builder separar bem os passos de construção, o Director tem um controle bem maior sobre a produção do Produto.
*
*
BUILDER
Um problema com o padrão é que é preciso sempre chamar o método de construção para depois utilizar o produto em si. No nosso exemplo essa responsabilidade foi dada ao código cliente. No entanto a classe Director poderia realizar todas as chamadas em um único método e depois apenas retornar o produto final ao cliente
*
*
BUILDER
Conseqüências do padrão Builder: 
· O Builder deixa você variar a representação interna do produto que ele
cria. Ele também esconde os detalhes de como o produto é montado. 
· Cada Builder específico é independente de outros e do resto do programa. Isso melhora a modularidade e faz a adição de outros Builder relativamente simples. 
· Como cada Builder constrói o produto final passo-a-passo, dependendo dos dados, você tem mais controle sobre o produto final construído. O padrão Builder é algo como o Abstract Factory, na qual ambos retornam feitas de um número de métodos e objetos. A principal diferença é que enquanto o Abstract Factory retorna uma família de classes relacionadas, o Builder constrói um objeto complexo passo-a-passo, dependendo dos dados apresentados a ele. 
*
*
BUILDER
Padrões Relacionados: 
· INTERFACE - O padrão Builder usa o padrão Interface para esconder a classe atual do objeto que ela constrói. 
· COMPOSITE - O objeto construído pelo Builder é tipicamente um Composite. 
· FACTORY METHOD - O padrão Builder usa o padrão Factory para decidir que classe concreta instanciar para construir o tipo de objeto desejado. 
· LAYERED INITIALIZATION - O padrão Builder usa o padrão Layered Initialization para cria objetos que constroem o tipo de objeto desejado. 
*
*
BUILDER
*
*
BUILDER
*
*
BUILDER
PASSO A PASSO:
Cria-se a classe de modelo, a classe que será realmente o produto final
Com o modelo pronto, o mesmo deve ser instanciado no construtor de uma classe abstrata a qual possui como assinatura os métodos/operações para construção de cada atributo do produto/classe concreta e um atributo do produto.
Cria-se então o Builder concreto o qual estende a classe abstrata que constrói o produto final, é importante saber que nessa classe que se dará a criação dos atributos da classe concreta
 Após isso cria-se a classe Director a qual possuirá uma tributo do tipo da classe abstrata, dentro do construtor dessa classe passa-se o atributo sendo uma classe abstrata e com isso o atributo será responsável por construir suas partes num método void construirProduto;
*
*
BUILDER
EXEMPLO CARRO
*
*
BUILDER
EXERCÍCIO COMPUTADOR:
Criar um computador com uma configuração default através do padrão builder.
*
*
*
*
PADRÕES DE CRIAÇÃO
PROTOTYPE
*
*
PROTOTYPE
Padrão que permite a criação de um objeto a partir de um modelo original, criação de um objeto a partir de um clone de uma instância-protótipo.
	Quando temos uma classe que irá gerar muitas heranças e não queremos utilizar herança.
Possui os seguinte elementos:
PROTOTYPE — uma classe que declara uma interface para objetos capazes de clonar a si mesmo;
PROTOTYPE CONCRETO — implementação de um prototype;
CLIENTE — cria um novo objeto através de um prototype que é capaz de clonar a si mesmo.
*
*
PROTOTYPE
*
*
PROTOTYPE
Efetivamente, cada objeto é, ele próprio, um factory especializado em construir objetos iguais a si mesmo.
Quando utiliza-lo:
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;
sistemas que possuem componentes cujo estado inicial possui poucas variações e onde é conveniente disponibilizar um conjunto pré-estabelecido de protótipos que dão origem aos objetos que compõem o sistema.
*
*
PROTOTYPE
Consequências:
Reduz o número de classes que os clientes conhecem
Permitem que o cliente trabalhe com classes especificas sem necessidade de recompilação
Adiciona e remove produtos em tempo de execução
Especifica novos objetos através de variação na estrutura
Reduz o número de subclasses
Configuração dinâmica de aplicações
***Cada subclasse deve implementar um método clone()
*
*
PROTOTYPE
Quando utiliza o framework Spring, por exemplo, um desenvolvedor pode configurar um JavaBean como "prototype". Esta configuração faz com que cada uma das referências a um JavaBean aponte para uma instância diferente. O comportamento padrão, ou singleton, define que todas as referências a um JavaBean apontem para a mesma instância de uma classe
*
*
PROTOTYPE
*
*
PROTOTYPE
Observação: Na linguagem Java, a interface Cloneable não possui métodos e é utilizada apenas para indicar que o método Object.clone() pode realizar uma cópia, atributo por atributo, das instâncias de uma classe
*
*
PROTOTYPE
EXEMPLO PROTOTYPE:
Primeiro criamos uma interface que extends Clonable do Java, essa interface possui uma assinatura de um método cuja assinatura retorna um tipo de objeto a ser definido;
Depois cria-se a classe concreta que implementa a interface para criar a clonagem, dentro do método clonar dessa classe chama-se o método clone da super classe ou seja super.clone(), para criar o clone;
Após isso cria-se a classe protótipo a qual possui um atributo do tipo do objeto que se deseja criar, esta classe possui um método com retorno do tipo da interface o qual retorna o método clonar do seu atributo 
Sempre que o programa ou o cliente precisar de um protótipo com suas características originais basta chamar o getClone do objeto protótipo.
*
*
PROTOTYPE
EXERCÍCIOS:
CRIE PROTÓTIPOS PARA OBJETOS BICICLETA
CRIE PROTÓTIPOS PARA OBJETOS CARRO
*
*
BONS ESTUDOS
LEIAM O MATERIAL DIDÁTICO
E FAÇAM OS EXERCÍCIOS PROPOSTOS EM SALA, TANTO A PROGRAMAÇÃO EM JAVA QUANTO OS DIAGRAMAS DE CLASSES
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*