Padrões de Projeto - II - INF

Especialização em web com interfaces
ricas
Padrões de Projeto - II
Prof. Fabrízzio Alphonsus A. M. N. Soares
[email protected] [email protected]
Instituto de Informática
Universidade Federal de Goiás
Aula 7
25 de maio de 2012
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
1/74
Padrões de criação I
Factory Method
Abstract Factory
Builder
Prototype
Singleton
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
2/74
Factory Method I
Factory Method (Método de Fábrica) é um padrão de projeto
que visa encapsular a criação de um objeto em um método.
Factory Method é provavelmente um dos padrões mais utilizados porque ele é muito natural. Ele é usado, muitas vezes, sem
consciência de que está sendo usado um padrão.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
3/74
O Problema I
Você precisa criar um objeto mas você não quer usar a diretiva
new diretamente ou não sabe qual classe instanciar.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
4/74
A Solução I
Algumas razões existem para que não queria utilizar new diretamente. A primeira, e mais óbvia, é não saber que classe de
objeto instanciar.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
5/74
A Solução II
Isso é comum numa aplicação bem desenhada onde variáveis
são estruturadas com base em interfaces. Assim, vários tipos
de objetos diferentes podem ser associadas a essa variável.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
6/74
A Solução III
Uma outra razão é a necessidade de inicializar o objeto instanciado antes de ser atribuido à variável.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
7/74
A Solução IV
Importante notar que esta inicialização não depende do ambiente onde o objeto será utilizado, mas apenas da estrutura do
próprio objeto.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
8/74
A Implementação I
A implementação de Factory Method é tão simples quanto fazer
new dentro de um método. Não existe nenhum segredo.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
9/74
A Implementação II
Em particular o método pode ser estático.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
10/74
A Implementação III
Neste caso a criação do objeto é feita num escopo diferente da
criação feita dentro de um método de instancia. Mesmo assim,
se trata do mesmo padrão.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
11/74
O Modelo I
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
12/74
Estrutura I
O padrão Factory Method, da forma como foi descrito no livro
Design Patterns: Elements of Reusable Object-Oriented Software, contém os seguintes elementos:
Creator declara o factory method (método de fabricação)
que retorna o objeto da classe Product (produto).
Este elemento também pode definir uma
implementação básica que retorna um objeto de
uma classe ConcreteProduct (produto concreto)
básica;
ConcreteCreator sobrescreve o factory method e retorna um
objeto da classe ConcreteProduct;
Product define uma interface para os objectos criados pelo
factory method;
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
13/74
Estrutura II
ConcreteProduct uma implementação para a interface
Product.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
14/74
Exemplo I
Uma aplicação, que é construída através de um framework baseado no padrão Factory Method, suporta a criação de documentos do tipo MeuDocumento.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
15/74
Exemplo II
O framework é constituído pelas classes abstratas Aplicacao e
Documento. A aplicação disponibiliza as classes concretas MinhaAplicacao e MeuDocumento. A classe MinhaAplicacao é
uma implementação da abstração definida pela classe Aplicacao.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
16/74
Exemplo III
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
17/74
Exemplo IV
A chave deste padrão está na declaração do método abstrato
criaDocumento, da classe Aplicacao, e na sua utilização pelo
método novoDocumento.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
18/74
Exemplo V
Este arranjo permite que o método novoDocumento crie documentos sem conhecer os detalhes de implementação, existentes
em cada tipo de documento suportado pela aplicação.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
19/74
Exemplo VI
Isto permite que a implementação do método criaDocumento
(neste exemplo situada na classe MinhaAplicacao) varie livremente, para atender os diversos formatos possivelmente suportados, sem que seja necessário modificar o código das classes
abstratas.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
20/74
Código Java I
1
2
3
4
5
6
7
8
9
10
11
12
13
14
abstract class Aplicacao {
private Documento doc;
abstract Documento criaDocumento();
void novoDocumento() {
this.doc = this.criaDocumento();
}
void abrirDocumento() {
this.doc.abrir();
}
}
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
21/74
Código Java II
1
2
3
4
5
6
7
8
9
10
11
12
13
14
abstract class Documento {
void abrir() {
System.out.println("Documento:Abrir documento!");
}
void fechar() {
System.out.println("Documento:Fechar documento!");
}
void gravar() {
System.out.println("Documento:Gravar documento!");
}
}
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
22/74
Código Java III
1
2
3
4
5
6
class MinhaAplicacao extends Aplicacao {
Documento criaDocumento() {
return new MeuDocumento();
}
}
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
23/74
Código Java IV
1
2
3
class MeuDocumento extends Documento {
}
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
24/74
Abstract Factory I
Abstract Factory é um padrão de criação e como o nome diz
“Fabrica Abstrata” este padrão é utilizado para a criação de
objetos relacionados ou “família de objetos”.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
25/74
O Problema I
Precisamos criar famílias de objetos relacionados e cada objeto
de cada família tem sua implementação especifica.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
26/74
O Problema II
Você precisa garantir que dada uma situação você escolherá a
família correta de objetos que será utilizado sem misturar os
objetos de famílias diferentes.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
27/74
O Modelo I
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
28/74
Exemplo I
Imagine que você esteja desenvolvendo uma aplicação de gerenciamento de documentos (GED) e precise tratar diferentes
tipos de arquivos: txt, pdf, doc e etc.
Dentro deste contexto você terá objetos para extração e indexação de conteúdo para cada tipo de arquivo (mime-type).
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
29/74
Exemplo II
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
30/74
Código Java I
1
2
3
4
5
6
7
public interface DocumentFactory
{
public static final String TXT = "TXT";
public static final String PDF = "PDF";
public DocumentReader createDocumentReader( );
public DocumentWriter createDocumentWriter( );
}
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
31/74
Código Java II
1
2
3
4
5
import java.io.OutputStream;
public interface DocumentReader {
public OutputStream readeFile( String file );
}
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
32/74
Código Java III
1
2
3
4
5
import java.io.InputStream;
public interface DocumentWriter {
public void writeFile( InputStream inputStream );
}
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
33/74
Código Java IV
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class PdfDocumentFactory implements DocumentFactory
{
@Override
public DocumentReader createDocumentReader( )
{
System.out.println( "PdfDocumentFactory.
createDocumentReader ::: PDF" );
return new PdfDocumentReader( );
}
@Override
public DocumentWriter createDocumentWriter( )
{
System.out.println( "PdfDocumentFactory.
createDocumentWriter ::: PDF" );
return new PdfDocumentWriter( );
}
}
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
34/74
Código Java V
1
2
3
4
5
6
7
8
9
import java.io.OutputStream;
public class PdfDocumentReader implements DocumentReader {
@Override
public OutputStream readeFile( String file ) {
System.out.println( "PdfDocumentReader.readeFile ::: PDF
" );
return null;
}
}
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
35/74
Código Java VI
1
2
3
4
5
6
7
8
import java.io.InputStream;
public class PdfDocumentWriter implements DocumentWriter {
@Override
public void writeFile(InputStream inputStream) {
System.out.println( "PdfDocumentWriter.writeFile ::: PDF
" );
}
}
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
36/74
Código Java VII
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class TxtDocumentFactory implements DocumentFactory
{
@Override
public DocumentReader createDocumentReader( )
{
System.out.println( "TxtDocumentFactory.
createDocumentReader ::: TXT" );
return new TxtDocumentReader( );
}
@Override
public DocumentWriter createDocumentWriter( )
{
System.out.println( "TxtDocumentFactory.
createDocumentWriter ::: TXT" );
return new TxtDocumentWriter( );
}
}
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
37/74
Código Java VIII
1
2
3
4
5
6
7
8
9
import java.io.OutputStream;
public class TxtDocumentReader implements DocumentReader {
@Override
public OutputStream readeFile(String file) {
System.out.println( "TxtDocumentReader.readeFile ::: TXT
" );
return null;
}
}
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
38/74
Código Java IX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import java.io.OutputStream;
public class Client
{
public static void main(String[] args) throws Exception
{
DocumentFactory documentFactory = createDocumentFactory
( "PDF" );
DocumentWriter documentWriter = documentFactory.
createDocumentWriter();
documentWriter.writeFile( null );
DocumentReader documentReader = documentFactory.
createDocumentReader();
OutputStream outputStream = documentReader.readeFile("
dados.txt");
}
public static DocumentFactory createDocumentFactory( String
type )
{
if ( type.equalsIgnoreCase( DocumentFactory.PDF ) )
return new PdfDocumentFactory();
if( type.equalsIgnoreCase( DocumentFactory.TXT ) )
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
39/74
Código Java X
17
18
19
20
return new TxtDocumentFactory();
return null;
}
}
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
40/74
Utilizações comuns I
Utilize quando quiser ter independência de como seus objetos
são criados, ou seja você deseja desacoplar sua aplicação e as
famílias de objetos utilizadas por ela.
Dessa forma podemos trocar a família de objetos utilizadas na
aplicação sem afetar o código fonte.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
41/74
Utilizações comuns II
Utilize quando quiser fornecer uma biblioteca de classes de produtos e quer revelar somente suas interfaces e as implementações.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
42/74
Observação I
Embora utilizar o AbstractFactory gere um trabalho adicional
(escrever produtos abstratos, fabricas abstratas, e suas respectivas implementações), utilizar fabricas é uma boa prática de
programação e ajuda a reduzir o acoplamento e conseqüentemente melhora manutenção do sistema.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
43/74
Padrão Builder I
O padrão Builder (Montador) é um projeto que ajuda a criar objetos complexos; quer seja porque contém muitas propriedades e
várias configurações possíveis, ou porque contém uma estrutura
aninhada de objetos.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
44/74
O Problema I
Ao codificar orientado a objetos é comum representarmos entidades do sistema como estruturas de objetos aninhados ou
utilizar objetos no padrão Bean com várias propriedades.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
45/74
O Problema II
A construção de objetos deste tipo pode ser complexa e obrigar
a escrever muito código burocrático devido à estrutura interna
do objeto estar encapsulada.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
46/74
O Problema III
Construir um objeto complexo é uma tarefa chata, propensa a
erros e pouco controlável.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
47/74
A Solução I
A solução é definir um outro objeto que será responsável pela
criação correta do objeto que queremos construir.
Para que não haja confusão com o conceito de construtor, passarei a referir à responsabilidade do objeto que implementa o
padrão Builder como “montar”.
O objeto Builder é responsável por montar um outro objeto.
Este outro objeto é chamado, genericamente, de produto.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
48/74
A Solução II
O objeto Builder conta com vários métodos na sua interface de
forma a poder ser informado das características que o produto
terá e um método que realmente irá montar o produto e entregálo.
Opcionalmente a montagem pode ser explicitada em um outro método de forma a deixar mais claro quando acontece a
montagem.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
49/74
O Modelo I
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
50/74
O Modelo II
O padrão Builder, da forma como foi descrito no livro Design
Patterns: Elements of Reusable Object-Oriented Software, contém os seguintes elementos:
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.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
51/74
Exemplo I
Imaginemos que você tenha uma classe chamada Pizza e que
você pode querer construir objetos com uma quantidade variada
de parâmetros.
Uma forma seria criar construtores sobrecarregados:
1
2
3
4
Pizza(int size)
Pizza(int size,
Pizza(int size,
Pizza(int size,
) { ... }
{ ... }
boolean cheese) { ... }
boolean cheese, boolean pepperoni) { ... }
boolean cheese, boolean pepperoni, boolean bacon
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
52/74
Exemplo II
Isso é chamado de Construtor Telescoping Padrão. O problema com esse padrão é que uma vez construtores são 4 ou
5 parâmetros de longo torna-se difícil de lembrar a ordem dos
parâmetros exigidos, bem como o construtor especial que você
pode querer em uma determinada situação.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
53/74
Exemplo III
Uma alternativa que você tem para o construtor Telescoping
padrão é o padrão JavaBean quando você chamar um construtor com os parâmetros obrigatórios e, em seguida, ligar para
qualquer setters opcional depois:
1
2
3
4
Pizza pizza = new Pizza(12);
pizza.setCheese(true);
pizza.setPepperoni(true);
pizza.setBacon(true);
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
54/74
Exemplo IV
O problema aqui é que porque o objeto é criado durante várias
chamadas, pode estar em um estado inconsistente partway através de sua construção. Isso também exige um grande esforço
extra para garantir a segurança de discussão.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
55/74
Exemplo V
Uma boa alternativa seria a utilização do padrão construtor
(builder)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class Pizza {
private int size;
private boolean cheese;
private boolean pepperoni;
private boolean bacon;
public static class Builder {
private final int size;
private boolean cheese = false;
private boolean pepperoni = false;
private boolean bacon = false;
public Builder(int size) {
this.size = size;
}
public Builder cheese(boolean value) {
cheese = value;
return this;
}
public Builder pepperoni(boolean value) {
pepperoni = value;
return this;
}
public Builder bacon(boolean value) {
bacon = value;
return this;
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
56/74
Exemplo VI
25
26
27
28
29
30
31
32
33
34
35
36
}
public Pizza build() {
return new Pizza(this);
}
}
private Pizza(Builder builder) {
size = builder.size;
cheese = builder.cheese;
pepperoni = builder.pepperoni;
bacon = builder.bacon;
}
}
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
57/74
Exemplo VII
Note que a Pizza é imutável e que os valores dos parâmetros
estão todos em um único local. Como construtor setter métodos
de devolver o objeto Builder eles são capazes de ser acorrentado.
1
Pizza pizza = new Pizza.Builder(12).cheese(true).pepperoni(true)
.bacon(true).build();
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
58/74
Exemplo VIII
Isso resulta em um código que é fácil escrever e muito fácil de
ler e compreender. Neste exemplo, o método de construção
pode ser modificado para verificar os parâmetros após terem
sido copiados a partir do construtor para o objeto Pizza e lançar
uma IllegalStateException se um parâmetro inválido valor foi
fornecido.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
59/74
Exemplo IX
Este modelo é flexível e é fácil adicionar mais parâmetros para
ele no futuro. É realmente só é útil se você está indo ter mais
de 4 ou 5 parâmetros de um construtor. Dito isto, poderá ser
útil em primeiro lugar, se você suspeitar que você pode estar
adicionando parâmetros mais no futuro.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
60/74
O Padrão Prototype I
É um padrão de projeto que permite a criação de objetos a partir de um modelo original, ou seja, foi criado com o objetivo
de especificar os tipos de objetos a serem criados usando uma
instância-protótipo e criar novos objetos pela cópia desse protótipo. Efetivamente, cada objeto é um factory especializado em
construir objetos iguais a si mesmo.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
61/74
Estrutura I
O padrão Prototype contém os seguintes 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.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
62/74
Estrutura II
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
63/74
Estrutura III
O padrão Prototype exige a implementação de uma operação de
clonagem em cada uma das classes concretas do protótipo. Esta
tarefa pode ser inconveniente, no caso do reaproveitamento de
classes pré-existentes que não possuem tal operação, ou mesmo
complexa, se for considerada a possibilidade de existirem referências circulares nos atributos de um objeto (um objeto possui
um atributo que referência um objeto que, por sua vez, referência o objeto original).
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
64/74
Estrutura IV
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;
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
65/74
Estrutura V
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.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
66/74
Quando usar? I
Use o padrão Prototype quando um sistema tiver que ser independente de como os seus produtos são criados, compostos e
representados e:
Quando as classes a instanciar forem especificadas em
tempo de execução, por exemplo, por carga dinâmica;
Para evitar a construção de uma hierarquia de classes de
fábricas paralela à hierarquia de classes de produto;
Quando as instâncias de uma classe puderem ter uma
dentre poucas combinações diferentes de estados. Pode
ser mais conveniente instalar um número correspondente
de protótipos e cloná-los, ao invés de instanciar a classe
manualmente, cada vez com um estado apropriado.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
67/74
Desvantagem I
Cada subclasse de Prototype deve implementar a operação clone,
o que pode ser difícil.
Por exemplo, acrescentar clone é difícil quando as classes consideradas já existem. A implementação de clone pode ser complicada quando uma estrutura interna da classe inclui objetos que
não suportam operação de cópia ou têm referencias circulares.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
68/74
Padrão Singleton I
O padrão Singleton é um padrão que ajuda a criar objetos que
podem possuir uma única instância no sistema.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
69/74
O Problema I
Quando se possui elementos que são compartilhados entre módulos do sistema e não é admissível que hajam duas cópias de
objetos pois as informações devem ser comuns e a manutenção
deve ser compartilhada.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
70/74
A Solução I
Criar um objeto que não possa ser instanciado diretamente ou
que possua um mecanismo de contagem de instâncias para se
evitar que se crie um número de instâncias maior do que uma.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
71/74
Exemplo I
Uma das aplicações seria o compartilhamento de uma conexão
com o banco de dados, porém, sem manter uma instância até
que haja seu primeiro uso.
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
72/74
Código Java I
Em Java, é possível criar um Singleton criando um ou mais
construtores privados. Deve-se ser criado pelo menos um construtor privado, caso o contrário o compilador Java criará um
construtor público.
1
2
3
4
5
6
7
8
9
10
11
12
13
class ExemploSingleton{
ExemploSingleton instancia = null;
private ExemploSingleton(){
}
public static ExemploSingleton getInstance(){
if (instancia == null)
instancia = new ExemploSingleton();
return instancia;
}
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
73/74
Código Java II
14
}
Prof. Fabrízzio Alphonsus A. M. N. Soares | Padrões de Projeto - II
74/74