Singleton, é um padrão de projeto de software (do inglês Design Pattern). Este padrão garante a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto.
Nota linguística: O termo vem do significado em inglês quando se resta apenas uma carta nas mãos, num jogo de baralho.
Muitos projetos necessitam que algumas classes tenham apenas uma instância. Por exemplo, em uma aplicação que precisa de uma infraestrutura de log de dados, pode-se implementar uma classe no padrão singleton. Desta forma existe apenas um objeto responsável pelo log em toda a aplicação que é acessível unicamente através da classe singleton.
Exemplos
Em Java
Segue um exemplo em Java de classe Singleton usada em log de dados. Esta classe suporta inicialização sob demanda e ambientes multi-thread.public class SingletonLog {
// Construtor privado. Suprime o construtor publico padrao.
private SingletonLog() {
// Leitura da configuração de log. Normalmente descrita em um arquivo.
}
// Faz o log de eventos da aplicacao
public void doLog(String eventDescription) {
}
//Retorna a instancia unica da classe SingletonLog
public static SingletonLog getInstance() {
return SingletonLogHolder.instance;
}
//Classe auxiliar para criacao da instancia. Evita problemas de sincronizacao de threads.
private static class SingletonLogHolder {
private static SingletonLog instance = new SingletonLog();
}
}
quinta-feira, 8 de maio de 2008
AULA 17 e 18 - PADRÕES GOF
Os padrões de projeto de software ou padrões de desenho de software, também muito conhecido pelo termo original em inglês: Design Patterns, descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Um padrão de projeto estabelece um nome e define o problema, a solução, quando aplicar esta solução e suas conseqüências.
Os padrões de projeto visam facilitar a reutilização de soluções de desenho - isto é, soluções na fase de projeto do software, sem considerar reutilização de código. Também acarretam um vocabulário comum de desenho, facilitando comunicação, documentação e aprendizado dos sistemas de software.
Os padrões "GoF" são organizados em famílias de padrões: de criação, estruturais e comportamentais. Os padrões de criação são relacionados à criação de objetos, os estruturais tratam das associações entre classes e objetos e os comportamentais das interações e divisões de responsabilidades entre as classes ou objetos.
Um padrão "GoF" também é classificado segundo o seu escopo; de classe ou de objeto. Nos padrões com escopo de classe os relacionamentos que definem este padrão são definidos através de herança e em tempo de compilação. Nos padrões com escopo de objeto o padrão é encontrado no relacionamento entre os objetos definidos em tempo de execução.
Formas de classificação
- Classificação GOF
- Criação
- Estrutura
- Comportamento
- Classificação de hetsker
- Interface
- Responsabilidade
- Construção
- Operação
- Extensão
AULA 15 e 16 - COESÃO
Alta coesão é um princípio de ouro que deve ser sempre mantido em mente durante o projeto
Tipos de coesão entre módulos
· Coincidental (pior)
· Lógico
· Temporal
· Procedural
· De comunicação
· Sequencial
· Funcional (melhor)
Coesão coincidental
· Há nenhuma (ou pouca) relação construtiva entre os elementos de um módulo
· No linguajar OO:
· Um objeto não representa nenhum conceito OO
· Uma coleção de código comumente usado e herdado através de herança (provavelmente múltipla)
class Angu {
public static int
acharPadrão(String texto, String padrão) {
// ...
}
public static int média(Vector números) {
// ...
}
public static outputStream abreArquivo(string nomeArquivo) {
// ...
}
}
class Xpto extends Angu { // quer aproveitar código de Angu
...
}
Coesão lógica
· Módulo faz um conjunto de funções relacionadas, uma das quais é escolhida através de um parâmetro ao chamar o módulo
· Semelhante a acoplamento de controle
· Cura: quebrar em métodos diferentes
public void faça(int flag) {
switch(flag) {
case ON:
// coisas para tratar de
ON
break;
case OFF: // coisas para tratar de OFF
break;
case FECHAR:
// coisas para tratar de FECHAR
break;
case COR: // coisas para tratar de COR
break;
}
}
Tipos de coesão entre módulos
· Coincidental (pior)
· Lógico
· Temporal
· Procedural
· De comunicação
· Sequencial
· Funcional (melhor)
Coesão coincidental
· Há nenhuma (ou pouca) relação construtiva entre os elementos de um módulo
· No linguajar OO:
· Um objeto não representa nenhum conceito OO
· Uma coleção de código comumente usado e herdado através de herança (provavelmente múltipla)
class Angu {
public static int
acharPadrão(String texto, String padrão) {
// ...
}
public static int média(Vector números) {
// ...
}
public static outputStream abreArquivo(string nomeArquivo) {
// ...
}
}
class Xpto extends Angu { // quer aproveitar código de Angu
...
}
Coesão lógica
· Módulo faz um conjunto de funções relacionadas, uma das quais é escolhida através de um parâmetro ao chamar o módulo
· Semelhante a acoplamento de controle
· Cura: quebrar em métodos diferentes
public void faça(int flag) {
switch(flag) {
case ON:
// coisas para tratar de
ON
break;
case OFF: // coisas para tratar de OFF
break;
case FECHAR:
// coisas para tratar de FECHAR
break;
case COR: // coisas para tratar de COR
break;
}
}
AULA 14 - PADRÃO CONTROLLER
Controller
Problema
Quem deveria receber a responsabilidade de tratar eventos do sistema?
Um evento do sistema é um evento de alto nível gerado por um ator externo
Estão associados a operações do sistema que já vimos nos Diagramas de Sequência do Sistema
Exemplo do estudo de caso: Caixa pressiona "Fim de venda"
Solução
Use um controlador
Um controlador é um objeto que não é de interface GUI responsável pelo tratamento de eventos do sistema
Um controlador define métodos para as operações do sistema
Atribuir a responsabilidade pelo tratamento de eventos do sistema a uma classe de acordo com uma das alternativas abaixo:
Representa o "sistema" como um todo (facade controller)
Representa o negócio ou organização como um todo (facade controller)
Representa algo no mundo real que é ativo (por exemplo, o papel de uma pessoa) que poderia estar envolvido na tarefa (role controller)
Representa um handler artificial de todos os eventos do sistema para um Use Case particular, normalmente chamado "Handler" (use case controller)
Exemplo
No estudo de caso, há várias operações de sistema:
Quem deveria ser o controlador para os eventos do sistema?
Pelo padrão Controller, temos as seguintes alternativas:
Representa o "sistema": TPDV
Representa o negócio ou organização: Loja
Representa algo no mundo real ...: Caixa
Representa um handler artificial ...: CompraItemHandler
A escolha particular depende de fatores discutidos na seção Discussão
Por exemplo, se fosse TPDV, teríamos:
Discussão
De forma geral, o mesmo controlador deve ser usado para todas as operações de um mesmo Use Case de forma a manter a informação de estado do Use Case
A informação de estado pode ser útil para detectar sequências erradas de eventos de sistema
Exemplo: façaPagamento() antes de fimDeVenda()
Não coloque toda a inteligência no controlador
Delegue para outros objetos,para manter coesão
Use um Handler artificial quando as outras alternativas exibem acoplamento alto ou coesão baixa
Quando está surgindo um "God class"
Usado em sistemas mais complexos
Observe que classes "Window", "Applet", "Application", "View", "Document" não devem ser controladores
Tais classes podem receber o evento e delegá-lo ao controlador
Não se deve colocar business logic num objeto de interface com o usuário
Um design correto seria:
Um design incorreto seria:
O Role Controller pode levar a um mau projeto
O fato de algo ser feito por uma pessoa no mundo real não necessariamente significa que isso é uma boa alternativa em software
É mais comum "dar vida aos objetos" (não animados)
Consequências
Maior possibilidade de reuso, já que o business logic não está nos objetos de interface
Exemplo: embutir o business logic num objeto de interface não permitiria fazer EAI (Enterprise Application Integration)
Ajuda a verificar o sequenciamento das operações do sistema, através do estado do controlador
Responsabilidades, Role Playing e Cartões CRC
Embora não faça parte de UML, uma técnica chamada Cartões CRC é muito usada para atribuir responsabilidades durante o projeto
CRC = Class-Responsibility-Collaborations
CRC cards inventadas por Ward Cunningham e Kent Beck (Tektronix)Cartão CRC é um cartão pequeno (para só escrever o essencial) para cada classe
Escreve-se o nome da classe, suas responsabilidades e colaborações
Só pense nas responsabilidades de alto nível
São desenvolvidos em pequenos grupos em que cada pessoa assume o papel (Role) de uma ou mais classes
Mais detalhes aqui:
Designing Object-Oriented Software, Wirfs-Brock, Wilkerson e Wiener; Prentice Hall, 1990.
Algumas pessoas acham que é melhor usar ferramentas gráficas em vez de CRC Controller
Problema
Quem deveria receber a responsabilidade de tratar eventos do sistema?
Um evento do sistema é um evento de alto nível gerado por um ator externo
Estão associados a operações do sistema que já vimos nos Diagramas de Sequência do Sistema
Exemplo do estudo de caso: Caixa pressiona "Fim de venda"
Solução
Use um controlador
Um controlador é um objeto que não é de interface GUI responsável pelo tratamento de eventos do sistema
Um controlador define métodos para as operações do sistema
Atribuir a responsabilidade pelo tratamento de eventos do sistema a uma classe de acordo com uma das alternativas abaixo:
Representa o "sistema" como um todo (facade controller)
Representa o negócio ou organização como um todo (facade controller)
Representa algo no mundo real que é ativo (por exemplo, o papel de uma pessoa) que poderia estar envolvido na tarefa (role controller)
Representa um handler artificial de todos os eventos do sistema para um Use Case particular, normalmente chamado "Handler" (use case controller)
Exemplo
No estudo de caso, há várias operações de sistema:
Quem deveria ser o controlador para os eventos do sistema?
Pelo padrão Controller, temos as seguintes alternativas:
Representa o "sistema": TPDV
Representa o negócio ou organização: Loja
Representa algo no mundo real ...: Caixa
Representa um handler artificial ...: CompraItemHandler
A escolha particular depende de fatores discutidos na seção Discussão
Por exemplo, se fosse TPDV, teríamos:
Discussão
De forma geral, o mesmo controlador deve ser usado para todas as operações de um mesmo Use Case de forma a manter a informação de estado do Use Case
A informação de estado pode ser útil para detectar sequências erradas de eventos de sistema
Exemplo: façaPagamento() antes de fimDeVenda()
Não coloque toda a inteligência no controlador
Delegue para outros objetos,para manter coesão
Use um Handler artificial quando as outras alternativas exibem acoplamento alto ou coesão baixa
Quando está surgindo um "God class"
Usado em sistemas mais complexos
Observe que classes "Window", "Applet", "Application", "View", "Document" não devem ser controladores
Tais classes podem receber o evento e delegá-lo ao controlador
Não se deve colocar business logic num objeto de interface com o usuário
Um design correto seria:
Um design incorreto seria:
O Role Controller pode levar a um mau projeto
O fato de algo ser feito por uma pessoa no mundo real não necessariamente significa que isso é uma boa alternativa em software
É mais comum "dar vida aos objetos" (não animados)
Consequências
Maior possibilidade de reuso, já que o business logic não está nos objetos de interface
Exemplo: embutir o business logic num objeto de interface não permitiria fazer EAI (Enterprise Application Integration)
Ajuda a verificar o sequenciamento das operações do sistema, através do estado do controlador
Responsabilidades, Role Playing e Cartões CRC
Embora não faça parte de UML, uma técnica chamada Cartões CRC é muito usada para atribuir responsabilidades durante o projeto
CRC = Class-Responsibility-Collaborations
CRC cards inventadas por Ward Cunningham e Kent Beck (Tektronix)Cartão CRC é um cartão pequeno (para só escrever o essencial) para cada classe
Escreve-se o nome da classe, suas responsabilidades e colaborações
Só pense nas responsabilidades de alto nível
São desenvolvidos em pequenos grupos em que cada pessoa assume o papel (Role) de uma ou mais classes
Mais detalhes aqui:
Designing Object-Oriented Software, Wirfs-Brock, Wilkerson e Wiener; Prentice Hall, 1990.
Algumas pessoas acham que é melhor usar ferramentas gráficas em vez de CRC
Problema
Quem deveria receber a responsabilidade de tratar eventos do sistema?
Um evento do sistema é um evento de alto nível gerado por um ator externo
Estão associados a operações do sistema que já vimos nos Diagramas de Sequência do Sistema
Exemplo do estudo de caso: Caixa pressiona "Fim de venda"
Solução
Use um controlador
Um controlador é um objeto que não é de interface GUI responsável pelo tratamento de eventos do sistema
Um controlador define métodos para as operações do sistema
Atribuir a responsabilidade pelo tratamento de eventos do sistema a uma classe de acordo com uma das alternativas abaixo:
Representa o "sistema" como um todo (facade controller)
Representa o negócio ou organização como um todo (facade controller)
Representa algo no mundo real que é ativo (por exemplo, o papel de uma pessoa) que poderia estar envolvido na tarefa (role controller)
Representa um handler artificial de todos os eventos do sistema para um Use Case particular, normalmente chamado "
Exemplo
No estudo de caso, há várias operações de sistema:
Quem deveria ser o controlador para os eventos do sistema?
Pelo padrão Controller, temos as seguintes alternativas:
Representa o "sistema": TPDV
Representa o negócio ou organização: Loja
Representa algo no mundo real ...: Caixa
Representa um handler artificial ...: CompraItemHandler
A escolha particular depende de fatores discutidos na seção Discussão
Por exemplo, se fosse TPDV, teríamos:
Discussão
De forma geral, o mesmo controlador deve ser usado para todas as operações de um mesmo Use Case de forma a manter a informação de estado do Use Case
A informação de estado pode ser útil para detectar sequências erradas de eventos de sistema
Exemplo: façaPagamento() antes de fimDeVenda()
Não coloque toda a inteligência no controlador
Delegue para outros objetos,para manter coesão
Use um Handler artificial quando as outras alternativas exibem acoplamento alto ou coesão baixa
Quando está surgindo um "God class"
Usado em sistemas mais complexos
Observe que classes "Window", "Applet", "Application", "View", "Document" não devem ser controladores
Tais classes podem receber o evento e delegá-lo ao controlador
Não se deve colocar business logic num objeto de interface com o usuário
Um design correto seria:
Um design incorreto seria:
O Role Controller pode levar a um mau projeto
O fato de algo ser feito por uma pessoa no mundo real não necessariamente significa que isso é uma boa alternativa em software
É mais comum "dar vida aos objetos" (não animados)
Consequências
Maior possibilidade de reuso, já que o business logic não está nos objetos de interface
Exemplo: embutir o business logic num objeto de interface não permitiria fazer EAI (Enterprise Application Integration)
Ajuda a verificar o sequenciamento das operações do sistema, através do estado do controlador
Responsabilidades, Role Playing e Cartões CRC
Embora não faça parte de UML, uma técnica chamada Cartões CRC é muito usada para atribuir responsabilidades durante o projeto
CRC = Class-Responsibility-Collaborations
CRC cards inventadas por Ward Cunningham e Kent Beck (Tektronix)Cartão CRC é um cartão pequeno (para só escrever o essencial) para cada classe
Escreve-se o nome da classe, suas responsabilidades e colaborações
Só pense nas responsabilidades de alto nível
São desenvolvidos em pequenos grupos em que cada pessoa assume o papel (Role) de uma ou mais classes
Mais detalhes aqui:
Designing Object-Oriented Software, Wirfs-Brock, Wilkerson e Wiener; Prentice Hall, 1990.
Algumas pessoas acham que é melhor usar ferramentas gráficas em vez de CRC Controller
Problema
Quem deveria receber a responsabilidade de tratar eventos do sistema?
Um evento do sistema é um evento de alto nível gerado por um ator externo
Estão associados a operações do sistema que já vimos nos Diagramas de Sequência do Sistema
Exemplo do estudo de caso: Caixa pressiona "Fim de venda"
Solução
Use um controlador
Um controlador é um objeto que não é de interface GUI responsável pelo tratamento de eventos do sistema
Um controlador define métodos para as operações do sistema
Atribuir a responsabilidade pelo tratamento de eventos do sistema a uma classe de acordo com uma das alternativas abaixo:
Representa o "sistema" como um todo (facade controller)
Representa o negócio ou organização como um todo (facade controller)
Representa algo no mundo real que é ativo (por exemplo, o papel de uma pessoa) que poderia estar envolvido na tarefa (role controller)
Representa um handler artificial de todos os eventos do sistema para um Use Case particular, normalmente chamado "
Exemplo
No estudo de caso, há várias operações de sistema:
Quem deveria ser o controlador para os eventos do sistema?
Pelo padrão Controller, temos as seguintes alternativas:
Representa o "sistema": TPDV
Representa o negócio ou organização: Loja
Representa algo no mundo real ...: Caixa
Representa um handler artificial ...: CompraItemHandler
A escolha particular depende de fatores discutidos na seção Discussão
Por exemplo, se fosse TPDV, teríamos:
Discussão
De forma geral, o mesmo controlador deve ser usado para todas as operações de um mesmo Use Case de forma a manter a informação de estado do Use Case
A informação de estado pode ser útil para detectar sequências erradas de eventos de sistema
Exemplo: façaPagamento() antes de fimDeVenda()
Não coloque toda a inteligência no controlador
Delegue para outros objetos,para manter coesão
Use um Handler artificial quando as outras alternativas exibem acoplamento alto ou coesão baixa
Quando está surgindo um "God class"
Usado em sistemas mais complexos
Observe que classes "Window", "Applet", "Application", "View", "Document" não devem ser controladores
Tais classes podem receber o evento e delegá-lo ao controlador
Não se deve colocar business logic num objeto de interface com o usuário
Um design correto seria:
Um design incorreto seria:
O Role Controller pode levar a um mau projeto
O fato de algo ser feito por uma pessoa no mundo real não necessariamente significa que isso é uma boa alternativa em software
É mais comum "dar vida aos objetos" (não animados)
Consequências
Maior possibilidade de reuso, já que o business logic não está nos objetos de interface
Exemplo: embutir o business logic num objeto de interface não permitiria fazer EAI (Enterprise Application Integration)
Ajuda a verificar o sequenciamento das operações do sistema, através do estado do controlador
Responsabilidades, Role Playing e Cartões CRC
Embora não faça parte de UML, uma técnica chamada Cartões CRC é muito usada para atribuir responsabilidades durante o projeto
CRC = Class-Responsibility-Collaborations
CRC cards inventadas por Ward Cunningham e Kent Beck (Tektronix)Cartão CRC é um cartão pequeno (para só escrever o essencial) para cada classe
Escreve-se o nome da classe, suas responsabilidades e colaborações
Só pense nas responsabilidades de alto nível
São desenvolvidos em pequenos grupos em que cada pessoa assume o papel (Role) de uma ou mais classes
Mais detalhes aqui:
Designing Object-Oriented Software, Wirfs-Brock, Wilkerson e Wiener; Prentice Hall, 1990.
Algumas pessoas acham que é melhor usar ferramentas gráficas em vez de CRC
domingo, 23 de março de 2008
AULA 11, 12 e 13 - ACOPLAMENTO DE CONTROLE
Acoplamento de controle
Passar flags de controle entre objetos de forma que um objeto controle as etapas de processamento de outro objeto
Ocorrência comum:
Objeto a manda uma mensagem para objeto b
b usa um parâmetro da mensagem para decidir o que fazer class Lampada {
public final static int ON = 0;
public void setLampada(int valor) {
if(valor == ON) {
// liga lampada
} else if(valor == 1) {
// desliga lampada
} else if(valor == 2) {
// pisca
}
}
}
Lampada lampapa = new Lampada();
lampada.setLampada(Lampada.ON);
lampada.setLampada(2);
Solução: decompor a operação em múltiplas operações primitivas class Lampada {
public void on() { // liga lampada }
public void off() { // desliga lampada }
public void pisca() { // pisca }
}
Lampada lampada = new Lampada();
lampada.on();
lampada.pisca();
Ocorrência comum:
Objeto a manda mensagem para objeto b
b retorna informação de controle para a
Exemplo: retorno de código de erro class Teste {
public int printFile(File aImprimir) {
if(aImprimir está corrompido ) {
return CORRUPTFLAG;
}
// etc. etc.
}
}
Teste umTeste = new Teste();
int resultado = umTese.printFile(miniTeste);
if(resultado == CORRUPTFLAG) {
// oh! oh!
} else if(resultado == -243) {
// etc. etc.
Solução: use exceções class Teste {
public int printFile(File aImprimir) throws PrintExeception {
if(aImprimir está corrompido ) {
throw new PrintExeception();
}
// etc. etc.
}
}
try {
Teste umTeste = new Teste();
umTeste.printFile(miniTeste);
} catch(PrintException printError) {
// mail para a turma: não tem miniteste amanhã!
}
Passar flags de controle entre objetos de forma que um objeto controle as etapas de processamento de outro objeto
Ocorrência comum:
Objeto a manda uma mensagem para objeto b
b usa um parâmetro da mensagem para decidir o que fazer class Lampada {
public final static int ON = 0;
public void setLampada(int valor) {
if(valor == ON) {
// liga lampada
} else if(valor == 1) {
// desliga lampada
} else if(valor == 2) {
// pisca
}
}
}
Lampada lampapa = new Lampada();
lampada.setLampada(Lampada.ON);
lampada.setLampada(2);
Solução: decompor a operação em múltiplas operações primitivas class Lampada {
public void on() { // liga lampada }
public void off() { // desliga lampada }
public void pisca() { // pisca }
}
Lampada lampada = new Lampada();
lampada.on();
lampada.pisca();
Ocorrência comum:
Objeto a manda mensagem para objeto b
b retorna informação de controle para a
Exemplo: retorno de código de erro class Teste {
public int printFile(File aImprimir) {
if(aImprimir está corrompido ) {
return CORRUPTFLAG;
}
// etc. etc.
}
}
Teste umTeste = new Teste();
int resultado = umTese.printFile(miniTeste);
if(resultado == CORRUPTFLAG) {
// oh! oh!
} else if(resultado == -243) {
// etc. etc.
Solução: use exceções class Teste {
public int printFile(File aImprimir) throws PrintExeception {
if(aImprimir está corrompido ) {
throw new PrintExeception();
}
// etc. etc.
}
}
try {
Teste umTeste = new Teste();
umTeste.printFile(miniTeste);
} catch(PrintException printError) {
// mail para a turma: não tem miniteste amanhã!
}
AULA 9 E 10 - GRASP Padrão criador cont
//METODO ACESSOR
public string getDescricao() {
return Descricao;
}
//METODO MUTATORIO
Public void setDescricao(string valor) {
descricao = valor;
}
Public class itemvenda() {
Private double qtde;
Private produto P;
}
public void setP(produto p) {
this.p = p;
}
Public classe venda() {
//Porque usa set? Baixo acomplamento porque a HASH está ligada na SET.
Private set itemvendalist = new hashset();
Private date Datavenda;
Private integer idvenda;
Public criaritemvenda(produto,double qtde) {
itemvenda i = new itemvenda() ;
i.set(p);
i.setqtde(qtde);
itemvendalist.add(i);
}
public string getDescricao() {
return Descricao;
}
//METODO MUTATORIO
Public void setDescricao(string valor) {
descricao = valor;
}
Public class itemvenda() {
Private double qtde;
Private produto P;
}
public void setP(produto p) {
this.p = p;
}
Public classe venda() {
//Porque usa set? Baixo acomplamento porque a HASH está ligada na SET.
Private set
Private date Datavenda;
Private integer idvenda;
Public criaritemvenda(produto,double qtde) {
itemvenda i = new itemvenda() ;
i.set(p);
i.setqtde(qtde);
itemvendalist.add(i);
}
AULA 7 E 8 - GRASP Padrão criador
Problema: Quem deve criar novas instancias de uma classe?
Solução: Atribuir a classe B a resonsabilidade de criar instancias de A quando.
a) B agrega objetos de classe A
b) B contém instancias de A
c) B usa uma coleção de A
d) B possui os dados para criar A
B é criador de A se mais de uma opção se aplica
Exemplo
No estudo de caso, quem deveria criar uma instância de LinhaDetalheVenda?
Pelo padrão Creator, precisamos achar alguém que agrega, contém, ... instâncias de LinhaDetalheVenda
Considere o modelo conceitual parcial abaixo:
Venda agrega instâncias de LinhaDetalheVenda e é portanto um bom candidato para criar as instâncias
Chegamos aos seguintes diagramas:
Discussão
Escolhemos um criador que deve estar conectado ao objeto criado, de qualquer forma, depois da criação
Isso leva a fraco acoplamento
Exemplo de criador que possui os valores de inicialização
Uma instância de Pagamento deve ser criada
A instância deve receber o total da venda
Quem tem essa informação? Venda
Venda é um bom candidato para criar objetos da classe Pagamento
Consequências
Fraco acoplamento, já que o objeto criado deve normalmente ser visível ao criador, depois da criação
Solução: Atribuir a classe B a resonsabilidade de criar instancias de A quando.
a) B agrega objetos de classe A
b) B contém instancias de A
c) B usa uma coleção de A
d) B possui os dados para criar A
B é criador de A se mais de uma opção se aplica
Exemplo
No estudo de caso, quem deveria criar uma instância de LinhaDetalheVenda?
Pelo padrão Creator, precisamos achar alguém que agrega, contém, ... instâncias de LinhaDetalheVenda
Considere o modelo conceitual parcial abaixo:
Venda agrega instâncias de LinhaDetalheVenda e é portanto um bom candidato para criar as instâncias
Chegamos aos seguintes diagramas:
Discussão
Escolhemos um criador que deve estar conectado ao objeto criado, de qualquer forma, depois da criação
Isso leva a fraco acoplamento
Exemplo de criador que possui os valores de inicialização
Uma instância de Pagamento deve ser criada
A instância deve receber o total da venda
Quem tem essa informação? Venda
Venda é um bom candidato para criar objetos da classe Pagamento
Consequências
Fraco acoplamento, já que o objeto criado deve normalmente ser visível ao criador, depois da criação
Assinar:
Postagens (Atom)