Singleton com mais instancias

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

pcalcado wrote:

1 - Nao senhor. Global nao quer dizer que ha apenas um, quer dizer que esta disponivel globalmente. Um objeto definido como variavel global em C++ nao eh um singleton, por exemplo.

Nao invente o qu nao esta escrito, leia a definicao:

http://www.google.com.br/search?hl=pt-BR&q=define%3Aglobal&meta=

2 - NADA impede que voce tenha mais de um registry

Então vejamos....
O padrão registry não cria uma objeto Registry, por isso não tem como ter dois. O registry é uma classe em que os métodos são todos estáticos. O estado é encapsulado e a unica coisa que se vê são os métodos. Exemplo :

Isto é usado assim :

Em qualquer ponto do codigo vc pode fazer estas chamadas e elas sempre funcionarão.É isto que significa ser global. Como o seu link mesmo explica
"Pertaining to information available to more than one program or subroutine. "

O objeto retornado é o mesmo que registrado. Com isto eu ganho o mesmo efeito que um Singleton (unica instancia, acesso global) sem ter que usar o Singleton.getInstance(). Mas se tomar atenção verá que o Registry na realidade permite vários singletons. Tudo depende da implementação do Registry e poderia implementa um registry de factories que retorna N objetos.

Como Registry é abstract vc não conseguirá criar nenhuma instancia dele e como tem construtor privado não conseguirá herdá-lo para criar depois instancias. Por isso Registry é uma especialização de Singleton.
Mesmo que conseguisse herdá-lo como seus métodos são estáticos de nada adiantaria. Se isto não impede ter mais do que um registry então por favor escreva um código onde vc cria várias instâncias daquela classe Registry.

Global não quer dizer que ha apenas um ? Teoricamente não, mas tecnicamente sim. Suponha que vc tem 2 objetos Registry x e y (isto supondo que vc os consegue criar ) ora como eu executo o método em cima de x ? Por favor escreva um codigo demonstrado que vc consegue trabalhar com 2 objectos globais simultaneamente SEM usar singleton ou outro registry. .... .... .... a solução simples é criar um Map numa classe qualquer e coloca x e y lá assim :

Ora, mas esse Auxiliar tem um mapa que é um objeto global. Então para poder dois registry globais eu tenho que ter 1 único mapa global. Não tem outra forma de fazer isto, vc é obrigado a ter um objecto global único em algum ponto do design. Mas vc é livre de criar uma classe que possibilite
trabalhar como vários objetos globais SEM usar um objeto global para ter acesso a eles. Fico à espera....

Supondo que vc consegue fazer isso, pense na utilidade de ter dois registros globais. Se eu registro todos os meus serviços no x , por exemplo, para quê eu preciso do y ? O objetivo de ser global é intrinsecamente que seja único porque não ha utilidade em ser global e multiplo.

Relativamente a IoC. Imagine que vc está usando uma das BeanFactories do Spring. Nada o impede de criar duas instancias da mesma fábrica, pois elas não são Singleton nem Registry. Usemos da XMLBeanFactory , podemos até pensar que será usado o mesmo arquivo xml de configuração para as duas. Nesse arquivo definimos um bean para ser singleton. Ele é realmente singleton ?
Não, porque cada instancia do factory terá o seu. Portanto IoC sozinho não garante que existirá 1 e apenas 1 objeto daquela classe de bean. Para vc garantir isso tem que criar um Registry ou um Singleton que garante que apenas um Factory daquele bean poderá ser construida. Obviamente que ninguem é louco de criar 2 factories para os mesmos beans, da mesma forma que ninguem é louco de driblar um singleton via reflection (até pq não teria qualquer efeito no sistema. as classes normais continuariam chamado Singleton.getInstance e obtendo sempre o mesmo objeto, não vendo nunca que existem mais. ) Mas o fato de ninguem ser louco para usar isso, não significa que não possa. Ora o objetivo do Singleton é impedir que possa! E ai que está o seu poder.
Para começar o singleton tem que ser final e ter constutor privado. Se alguma destas é falsa já não é um singleton. Tem que haver uma forma de obter o objeto , mas não implica que seja sempre o mesmo objeto a ser retornado. Por exemplo, o singleton pode ser implementado com weakreference e quando ninguem está usado ele simplesmente desaparece sendo criado quando voltar a ser necessário. O que o padrão tem que garantir é que ao longo do programa o resto da aplicação vê 1 e apenas 1 objeto daquela classe. Mesmo usando reflection para criar vários objetos da classe vc não tem como enganar a aplicação a usar elas todas, a mesmo que force isso, e ai a sua classe deixa de ser a implementação do padrão Singleton.

Como vimos IoC por si mesma não substitui o padrão Singleton. Registry tb não embora possa ser usado como um ele não garante a unicidade. Nenhum outro padrão resolve sem ser o Singleton e isto deveria ser obvio desde um inicio pois se ele não fosse a unica solução ele não seria um padrão para começo de conversa)

Alguém pode me dizer uma coisa, pq todo thread tem que virar um flame apaixonado?

Isso tá quase parecendo SCO vs IBM!

sergiotaborda wrote:Não tem outra forma de fazer isto, vc é obrigado a ter um objecto global único em algum ponto do design. Mas vc é livre de criar uma classe que possibilite
trabalhar como vários objetos globais SEM usar um objeto global para ter acesso a eles. Fico à espera...

Eu entendi o seu ponto, mas existe sim essa forma. Você não precisa criar um jeito estático de acessar o seu objeto único. Tem só um conflito de conceitos bem comum aqui.

Se você expõe um jeito global de acessar o seu objeto é porque os outros objetos estão precisando ir atrás daquilo que precisam. A IoC (ou antes que alguém me xingue, a DIP) diz para você fazer exatamente o contrário: em vez dos seus objetos saírem atrás de tudo que precisam para fazer o trabalho, o que eles precisam será fornecido, como dependências.

Dessa forma você não precisa de um acesso global. Só vai propagando o que precisa ser propagado. Ex. (tosco):

e:

O exemplo é horrível, o importante é perceber o baixo acoplamento e a divisão de responsabilidades, já que cada objeto faz aquilo que foi criado para fazer e não tem que se preocupar de onde (ou qual método estático em que lugar global) pegar o que precisa.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Fabio Kung wrote:

sergiotaborda wrote:Não tem outra forma de fazer isto, vc é obrigado a ter um objecto global único em algum ponto do design. Mas vc é livre de criar uma classe que possibilite
trabalhar como vários objetos globais SEM usar um objeto global para ter acesso a eles. Fico à espera...

Eu entendi o seu ponto, mas existe sim essa forma. Você não precisa criar um jeito estático de acessar o seu objeto único. Tem só um conflito de conceitos bem comum aqui.

Se você expõe um jeito global de acessar o seu objeto é porque os outros objetos estão precisando ir atrás daquilo que precisam. A IoC (ou antes que alguém me xingue, a DIP) diz para você fazer exatamente o contrário: em vez dos seus objetos saírem atrás de tudo que precisam para fazer o trabalho, o que eles precisam será fornecido, como dependências.

O DIP não resolve o problema que o Singleton se propõe resolver.
Mesmo com um injector que use sempre o mesmo objecto durante a injecção isso não garante que existe apenas esse objecto.
Eu posso criar outro injector ou eu posso criar o bean na mão e fazer a injeção na mão. Nenhuma destas opções garanteque exista apenas uma instância da classe. A única forma de garantir que existe 1 e 1 só objeto de uma certa classe é com o padrão Singleton.

As questões são:
1)O Singleton implica em usar objetos declarados estáticamente na classe ? Não. Essa é apenas a implementação mais simples e comum do padrão. Vc poderia usar, por exemplo, JNDI e manter o objeto lá.

2) O Singleton implica em usar objectos globais ?
Sim. Mesmo usando JNDI vc está usando objectos globais. Aliás esse é o ppr conceito do JNDI. Se vc usar so os atributos estáticos da mesma forma será um objecto global. se usar Regestry pra mascarar o singleton, da mesma forma será um objeto global. Nâo existe uma forma de garantir unicidade sem objeto global. Se vc usar um factory DIP vc só garante unicidade se o factory, ele mesmo, for global.

3) IoC ou DIP subtituem Singleton ?
Não. E espero já estar claro pq.

4) Singleton é um padrão ruim?
Não. Implementações menos cuidadas de singleton é que podem ser ruins.

5) Criar instancias da classe que é supostamente um singleton usando reflection é uma violação do padrão singleton ?
Não. Porque vc só consegue fazer isso se a implementação de singleton deixar. Basta que o Singleton force o uso de um SecurityManager para que isso não aconteça. É tudo uma questão de implementação.

6) implementar um Singleton absoluto é dificil ?
Sim. Muito dificil. Por isso as implementações de singleton se limitam a respeitar os requisitos do sistema que as vai usar e pronto.

7) Registry subtitui Singleton ?
Não. Registry mantém um estado de forma única e global (embora privada). Ou seja, o estado do Registry é um singleton.
Mas ao encapsular o estado do Registry dentro da própria classe, não tem mais que implementar singleton explicitamente. Registry não subtitui singleton porque ele mesmo usa esse padrão internamente. Acontece apenas que a implmentação do singleton é mais simples nesse caso especifico.

8) Ioc , DIP e Registry podem ser alternativas ao uso de singleton ?
sim. Em casos simples em que não existe uma real necessidade de um único objeto da classe por vez , eles podem ser usado. Ou seja, vc pode usar IoC , DIP e Registry se o seu objetivo é poupar o sistema de criar N objetos iguais quando 1 só chega. Mas deixa de ser alternativa no momento que é necessário garantir que só um pode ser criado.

Repare como sublinhei sempre garantir. Isto porque essa é a palavra chave do padrão singleton.

Vc levantou o problema de que a necessidade de usar singleton advem de não está usando DIP. Isso não é correto. Imagine uma classe onde eu injeto um serviço que usa recursos nativos e faz um processamento pesado que só pode ser usado em thread única. O serviço é responsável por sincronizar os pedidos de várias threads e enviar para o codigo nativo. Para garantir que ninguem cria duas instancias deste serviço (o que causaria problemas com o codigo nativo que só aceita um processo de cada vez) eu tenho que usar Singleton para implementar esse serviço. Depois no framework de inversão eu tenho que dizer que aquele bean não usa new e sim um método de factory. Repare que tenho que garantir que existe apenas um serviço mesmo antes de pensar em usar DIP e a garantia tem que existir mesmo se não usar DIP. Portanto DIP não resolve o problema.

JavaBaby Membro desde: 22/08/2005 19:01:35 Mensagens: 94 Offline

qmx wrote:Alguém pode me dizer uma coisa, pq todo thread tem que virar um flame apaixonado?

Isso tá quase parecendo SCO vs IBM!

Porque é esse, infelizmente, o principal efeito colateral dos trolls. Coloca todo mundo na defensiva e o negócio se desvirtua num bate-boca cujo único propósito é triunfar sobre o outro.

sergiotaborda wrote:Vc levantou o problema de que a necessidade de usar singleton advem de não está usando DIP. Isso não é correto.

Não não. O que eu critiquei foi o fato de ter um meio estático-global de acessar a sua única instância. O que eu critiquei foi o fato de você precisar expor esse meio global de acesso.

Se os seus objetos/componentes apenas declaram a dependência a um outro objeto, pouco os importa se a instância é única ou não. Um objeto deve se preocupar em prestar os serviços para os quais foi criado, eventualmente com a cooperação de outros objetos. Não ter que controlar o ciclo de vida de outros objetos.

Não estou condenando a necessidade de existência de instancias únicas. Realmente há aplicações onde são necessárias. O que estou condenando é quem depende dessa instância única precisar saber como ter a tal instância única, ou mesmo ter de saber que ela é única. Percebe o alto acoplamento? Seja por jndi, seja por um factory method estático com construtor privado, seja por uma factory, seja por um builder, seja de um registry.

Aliás, se você realmente precisar pegar coisas de um container ou de um registry, injete o registry ou o container em vez de fazer Registry.getService(MeuServico.class).

Exemplo: componentes compartilhando o mesmo servico que faz operação demorada e sincroniza diversas chamadas a procedimentos nativos.

Será que consigo testar os Componentes isoladamente? Não. Assim que eu tentar chamar o metodoUtil em qualquer um deles, vou estar testando o servico.trabalha() também. MUITO difícil de testar isoladamente e altíssimo acoplamento.

E assim?

E então? Todos os componentes usam a mesma única instância de MeuServico? Precisei de um jeito estático-global para acessá-la? O segredo é fazer com que os objetos não precisem ir atrás de suas dependências.

E se eu quiser testar os Componentes isoladamente?

Mas aí você me pergunta:

Qualquer um pode criar um segundo MeuServico! Quero garantir que a instância é sempre a mesma!

Tem seu fundo de razão. Mas por que alguém iria querer criar um novo MeuServico, se todo mundo recebe como dependência?

Tirar a responsabilidade do Componente saber como o ciclo de vida do serviço funciona, diminui o acoplamento, aumenta a testabilidade e permite que você troque o funcionamento do cliclo de vida do MeuServico sem afetar ninguém. Pode ser que a instância deva ser única hoje, amanhã você decidiu que era melhor fazer um pool; o impacto da mudança será nulo. Pegou a idéia?

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Fabio Kung wrote:
Aliás, se você realmente precisar pegar coisas de um container ou de um registry, injete o registry ou o container em vez de fazer Registry.getService(MeuServico.class).

Exemplo: componentes compartilhando o mesmo servico que faz operação demorada e sincroniza diversas chamadas a procedimentos nativos.
public class Componente { public Resultado metodoUtil() { MeuServico servico = Registry.getService(MeuServico.class); return servico.trabalha(); } }

E então? Todos os componentes usam a mesma única instância de MeuServico? Precisei de um jeito estático-global para acessá-la?

Sim. o código dentro de métodoUtil.
Ai vc deu a volta e deixou como

na realidade , para manter a coerencia, deveria ser

ups.. vc acabou de demonstrar que ao tirar o codigo de dentro de Componente vc teve que o colocar em outro lugar. E não tem outro jeito. O desafio é saber onde o colocar. Eu so estou dizendo que não ha como eliminar aquela chamada Registry.getService(MeuServico.class); independentemente de onde ela estiver.

Inversão de controle é muito bonito, mas alguem tem que continuar controlando. É apenas uma alteração de quem controla. O objecto que usa o serviço ou o objeto que cria o usuário do serviço. Mas não muda o fato de como obter o serviço. Vc pode encapsular o código de chamada ao registro da forma que quiser. Com dip ou sem dip , em algum lugar do codigo vc vai ter que usar o acesso global do registry. Você pode esconder isso. Mas o problema não é esse.
Eu entendo o seu ponto e eu o uso. A API publica não mostra objetos globais, eles são usados internamente. Tudo bem com isso. O ponto da questão é que eles existem e têm que existir e não ha como evitar a necessidade de usar objetos globais e unicos.

O segredo é fazer com que os objetos não precisem ir atrás de suas dependências.

Bom, então como fazer para que o código de teste não vá atrás do Registry para injectar no Componente ? como fazer para que nunca seja necessário nenhum codigo invocar Registry.getService(MeuServico.class) ?
Em algum ponto vc vai ter que escrever aquele código. Pode ser nos testes , pode ser no codigo interno da API , no classloader , como AOP sem AOP , pode até ser o usuário da API a ter que o escrever. Onde vc vai escrever muda a qualidade da sua API, mas não muda o fato que alguem vai ter que escrever. Aquele código vai ter que ser executado em algum ponto. Certo ?

Uma API de boa qualidade vc não vê os objectos globais. A API os esconde, disfarça , encapsula. É bom que haja encapsulamento. Mas é bom também que não se perca de vista que o objeto global existe e continua lá.
E só isso. Para criar softwares precisamos de variáveis globais. Podemos não saber que elas estão lá, ou sequer ter que as manipular, mas estamos usando-as. Vc mesmo concordou com isso. Então acho que é claro, aceitável e pacifico o ponto que venho defendendo de que DIP/IoC não substitui Singleton e que dizer que Singleton é ruim ou que não precisamos dele porque podemos usar IoC é um argumento desprovido de razão.

Mas aí você me pergunta:

Qualquer um pode criar um segundo MeuServico! Quero garantir que a instância é sempre a mesma!

Tem seu fundo de razão. Mas por que alguém iria querer criar um novo MeuServico, se todo mundo recebe como dependência?

Pela mesma razão que alguém tentaria driblar um singleton com reflection... tem gente que não tem nada que fazer ... :wink:

(Veja com atenção o código que vc escreveu : nem todo o mundo tem como receber como dependência e ai é que está o ponto. O codigo de teste não o recebe como dependência, ele tem que usar o registro explicitamente)

sergiotaborda wrote:
Então vejamos....
O padrão registry não cria uma objeto Registry, por isso não tem como ter dois. O registry é uma classe em que os métodos são todos estáticos. O estado é encapsulado e a unica coisa que se vê são os métodos. Exemplo :
...
Em qualquer ponto do codigo vc pode fazer estas chamadas e elas sempre funcionarão.É isto que significa ser global. Como o seu link mesmo explica
"Pertaining to information available to more than one program or subroutine. "

E o que isso tem a ver com um singleton? Voce esta deturpando abertamento conceitos para se fazer verdade.

Leia o Gof e veja que o Singleton eh um objeto que pode ser instanciado N vezes (onde N geralmente é igual a um). Nada, repito: nada impede que eu tenha duas instâncias de registries. Se isto é útil ou não é outra coisa, dependente do contexto.

Além do mais, Registry é o padrão por traz de JNDI. Se sua afirmação anterior fosse verdade deveria haver apenas uma arvore JNDI num sistema distribuido, acho desnecessario reafirmar que isso nao eh verdade.

Voce esta inferindo coisas baseado em opiniao, nao em logica.

sergiotaborda wrote:
O objeto retornado é o mesmo que registrado. Com isto eu ganho o mesmo efeito que um Singleton (unica instancia, acesso global) sem ter que usar o Singleton.getInstance().

Quem disse que devemos retornar o mesmo objeto instanciado? O Regsitry pode ser passado como outro objeto. Eu posso muito bem criar uma instancia nova de registry a cada chamada, possivlemente copiando as entradas de uma chamada original. por que isso nao eh um registry?

E qual o problema de ter varios registries, com servicos diferentes, num sistema? talvez com serviços iguais, se for util! Leia o GOF: singletons nao podem ter mais de N isntancias. Registries podem, se isso eh util depende do contexto, o que interessa eh que nao sao nem de longe a mesma coisa.

sergiotaborda wrote:
Mas se tomar atenção verá que o Registry na realidade permite vários singletons. Tudo depende da implementação do Registry e poderia implementa um registry de factories que retorna N objetos.

NAO EXISTEM VARIOS SINGLETONS!

Singleton tem N instancias, se ele possui mais que isso nao eh singleton, se nao ha controle sobre o numero de instancias (como quando acontece com o registry) nao eh um singleton.

sergiotaborda wrote:
Como Registry é abstract vc não conseguirá criar nenhuma instancia dele e como tem construtor privado não conseguirá herdá-lo para criar depois instancias.

E quem disse, alem de voce, que é abstrato?

sergiotaborda wrote:
Por isso Registry é uma especialização de Singleton.

Sua afirmacoes nao possuem logica com a bibliografia atual. Se voce confirmar que trata-se de sua opiniao. Muito bem, voce tem o direito de defender esta, mas nao eh a opiniao de todos (pelo contrario!) e vai contra a bibliografia de referencia e... bem.. contra o dicionario!

sergiotaborda wrote:
Mesmo que conseguisse herdá-lo como seus métodos são estáticos de nada adiantaria. Se isto não impede ter mais do que um registry então por favor escreva um código onde vc cria várias instâncias daquela classe Registry.

Onde, pelo amor de Zahl, os metodos de um registry sao estaticos? Quem afirmou isso além de você? Qual a jsutificativa? Quantos métodos de JNDI são estáticos?

sergiotaborda wrote:
Global não quer dizer que ha apenas um ? Teoricamente não, mas tecnicamente sim. Suponha que vc tem 2 objetos Registry x e y (isto supondo que vc os consegue criar ) ora como eu executo o método em cima de x ? Por favor escreva um codigo demonstrado que vc consegue trabalhar com 2 objectos globais simultaneamente SEM usar singleton ou outro registry. .... .... .... a solução simples é criar um Map numa classe qualquer e coloca x e y lá assim :

Um objeto global quer dizer disponivel globalmente, nao é uma variavel global.

De qualquer forma, ainda que quisesse, cada registry pode ter sua propria forma de ser obtido (nao eh um singleton mesmo, cada forma retorna um objeto diferente) .

sergiotaborda wrote:
Supondo que vc consegue fazer isso, pense na utilidade de ter dois registros globais. Se eu registro todos os meus serviços no x , por exemplo, para quê eu preciso do y ? O objetivo de ser global é intrinsecamente que seja único porque não ha utilidade em ser global e multiplo.

PODE PRECISAR, tudo depende do contexto. Voce nao pode afirmar que eu preciso ou nao, voce nao conhece os requisitos do sistema.

"Intrinsicamente unico" só porque voce quer. Dê uma olhada em qualquer programa em C que utilize variaveis globais e reafirme o que acabou de dizer.

Novamente: GLOBAL QUER DIZER ACESSIVEL GLOBALMENTE, NAO UNICO. Singleton eh um padrao que indica uma limitacao no numero do objetos existentes, geralmente apenas um.

sergiotaborda wrote:
Relativamente a IoC. Imagine que vc está usando uma das BeanFactories do Spring. Nada o impede de criar duas instancias da mesma fábrica, pois elas não são Singleton nem Registry. Usemos da XMLBeanFactory , podemos até pensar que será usado o mesmo arquivo xml de configuração para as duas. Nesse arquivo definimos um bean para ser singleton. Ele é realmente singleton ?

Não, porque cada instancia do factory terá o seu. Portanto IoC sozinho não garante que existirá 1 e apenas 1 objeto daquela classe de bean.

Só se adotarmos sua definição de Singleton. Para as definições do mundo real um Singleton é escopado, ou seja: pode ser unico em um classloadres, em uma JVM, em um servidor, etc.

sergiotaborda wrote:
Como vimos IoC por si mesma não substitui o padrão Singleton.

E não se propõe a ser. peloamordeZahl, preste antençao no debate antes de respoder.

Nao sei de onde voce eh mas as pessoas por aqui usam Singletons como variaveis globais, um comportamento que pode ser substituido por diversas tecnicas, entre elas IoC. Aprenda o cotenxto antes de entrar num debate!

sergiotaborda wrote:
Registry tb não embora possa ser usado como um ele não garante a unicidade.

Ah, agora um Registry pode ser um singleton, antes ele era um Singleton. Voce pode se decidir, por favor?

sergiotaborda wrote:
Nenhum outro padrão resolve sem ser o Singleton e isto deveria ser obvio desde um inicio

A pergunta é: resolve o que?

sergiotaborda wrote:
pois se ele não fosse a unica solução ele não seria um padrão para começo de conversa)

Ah, e quer dizer que o padrao eh a unica solucao para uma coisa? Na boa, de onde voce tira essas coisas? Dos livros eu sei que nao sao.

Recomendo fortemente que:

1) leia os livros sobre padroes de projetos (Fowler e GOF, ao menos)
2) procure um bom dicionario
3) Escreva seu proprio livro/paper/artigo com suas ideias que sao completamente contrarias aos livros do item (1)

Java Ninja Membro desde: 27/03/2006 14:23:57 Mensagens: 263 Offline

Acho que até o ponto ninguém mais discorda que a Injeção de dependência pode ou não ser usada, mas não substitui o uso de Registry ou Singleton. Acho que estamos sendo preciosistas e essa discussão não vai a lugar nenhum.
Não me importo se os métodos do Registry são estáticos ou não, se existe uma instância... que seja... não faz diferença. A questão de o Singleton ser único ou não, isso não me importa. Eu preciso de alguma coisa que me auxilie para guardar estado e não obrigue o sistema a refazer o mesmo trabalho diversas vezes, principalmente em uma realidade multithreading sobre a qual eu não tenha controle das chamadas (por exemplo, mdb, servlet, etc). Eu não tenho como injetar a dependência, de forma que tenho que recuperá-la de algum lugar. JNDI, Registry, Singleton... não me importa. A questão é que normalmente Singleton é fácil de implementar e resolve o problema.
Quanto à questão do acoplamento, qual é a diferença? Eu nunca vou mudar o jeito de trazer a instância e o resto não muda em nada. Com o registry não acontece exatamente a mesma coisa? Com a diferença, ainda, que eu tenho que conhecer a implementação do Registry E ainda por cima saber a chave para buscar o objeto que eu preciso. same f... thing.
Tudo bem, digam que é um lixo, mas dêem uma alternativa melhor e que seja realmente diferente em termos práticos. P.S.: Alguém algum dia precisou extender um singleton? Pode me explicar em que situação? Será que não estamos dourando a pílula sobre uma questão irrelevante? Será que o cara que escreveu singleton=Anti-pattern sabia do que estava falando ou simplesmente reproduziu o que alguém disse?

Abraço,

Armando

armando wrote:Acho que até o ponto ninguém mais discorda que a Injeção de dependência pode ou não ser usada, mas não substitui o uso de Registry ou Singleton.

Substitui quando o Singleton é mal utilizado, que é em 99% dos casos. Muito dificilmente se tem motivos para ter um Singleton num sistema.

armando wrote:
A questão de o Singleton ser único ou não, isso não me importa.

Simplesmente porque você não quer um Singleton, quer uma variável global. Podemos parar de chamar isso de Singleton já que não segue o padrão.

armando wrote:
Eu preciso de alguma coisa que me auxilie para guardar estado e não obrigue o sistema a refazer o mesmo trabalho diversas vezes, principalmente em uma realidade multithreading sobre a qual eu não tenha controle das chamadas (por exemplo, mdb, servlet, etc).
Eu não tenho como injetar a dependência, de forma que tenho que recuperá-la de algum lugar.

Ué, e qual o problema de usar IoC neste caso? "Uma realidade multithreading" é caso comum em aplicações J2EE e isso nunca foi problema.

armando wrote:
JNDI, Registry, Singleton... não me importa. A questão é que normalmente Singleton é fácil de implementar e resolve o problema.

Novamente: não é um singleton, é uma variável global.

armando wrote:
Quanto à questão do acoplamento, qual é a diferença? Eu nunca vou mudar o jeito de trazer a instância e o resto não muda em nada.

Que tal testabilidade, para começar?

armando wrote:
Com o registry não acontece exatamente a mesma coisa? Com a diferença, ainda, que eu tenho que conhecer a implementação do Registry

Tem por quê? Você pode abstrair o Registry usando uma Fcatory que retorna interface.

armando wrote:
E ainda por cima saber a chave para buscar o objeto que eu preciso. same f... thing.

É rui, não? Use IoC então, ora bolas.

armando wrote:
Tudo bem, digam que é um lixo, mas dêem uma alternativa melhor e que seja realmente diferente em termos práticos.

Já foi dada e você não explicou porque não poderia utilizar.

armando wrote:
P.S.: Alguém algum dia precisou extender um singleton? Pode me explicar em que situação? Será que não estamos dourando a pílula sobre uma questão irrelevante? Será que o cara que escreveu singleton=Anti-pattern sabia do que estava falando ou simplesmente reproduziu o que alguém disse?

Já precisei mas nunca estendi porque não é viável, sempre joguei fora e reescrevi o códigod e acesso. Dê manutenção um tempo num sistema de gente grande que use esta 'técnica' de variáveis globais e você vai precisar. Ah, mas é claro que geralmente você pode evitar isso escrevendo outro singleton que é 99% igual ao primeiro.

De uma vez por todas:

1) Singleton é um padrão que permite que hajam apenas uma ou N instâncias de um dado objeto. Se esta instância é obtida por um método (Factory methdo) estático isso não importa para o Singleton.

2) Utilizar um variável estática para guardar um objeto que é obtido por outros por um método estático não é um Singleton (ao menos não precisa ter) -é um Factory Method estático- e é uma péssima prática desde os tempos das linguagens procedurais (ver Yourdon, Page-Jones e etc.)

3) Em 99% dos casos pseudo-Singletons são utilizados para implementar o item (2)

4) IoC e Registry não substituem (1) -nem se propoem a isso- mas substituem plenamente (2) e são altamente recomendados neste caso.

sergiotaborda wrote:Eu so estou dizendo que não ha como eliminar aquela chamada Registry.getService(MeuServico.class); independentemente de onde ela estiver.

Bom... na hora de dar quote no meu post você apagou o código em que eu dei a alternativa ao Registry.getService(). Acho que você não entendeu muito bem o que eu quis dizer e deturpou tudo. Por favor, leia denovo com mais calma algum outro dia.

O que eu quis (e fiz) foi justamente eliminar a chamada estática global. E não precisei dela denovo para que a instância fosse única.

Mas tudo bem. Eu não sou pretencioso a ponto de querer de mudar a sua opinião. Ainda mais estando muito mais do que claro que não vai ser mudada.

Continue usando meios estáticos-globais para fazer os seus lookups e boa sorte.

pcalcado wrote: Leia o Gof e veja que o Singleton eh um objeto que pode ser instanciado N vezes (onde N geralmente é igual a um). Nada, repito: nada impede que eu tenha duas instâncias de registries. Se isto é útil ou não é outra coisa, dependente do contexto.

Lendo o Gof eu não encontrei esta parte onde o Singleton pode ser instanciado N vezes, isso foi na pagina 130 - 135, se é citado em outro lugar eu gostaria de ler, sem sacanagem alguma.

pcalcado wrote: Leia o Gof e veja que o Singleton eh um objeto que pode ser instanciado N vezes (onde N geralmente é igual a um). Nada, repito: nada impede que eu tenha duas instâncias de registries. Se isto é útil ou não é outra coisa, dependente do contexto.

Philip, quando há um numero X de instancias, isto não caracteriza um poll em vez de um singleton?

todas as referencias que encontrei a singleton diziam que era apenas uma instancia ...

Eu considero Singleton como uma forma de controlar a isntanciação, por isso falei em N instâncias mas você está certo de que a maioria das refer~encias aponta para apenas uma. Eu odeio o termo Multiton.

Entretanto, um pool é algo diferente. Neste recursos são utilizados como Value Objects, sem identidade, mas anda impede que se instancie outros (a menos que estejamos falando de coisas diferentes).

pcalcado wrote:
Entretanto, um pool é algo diferente. Neste recursos são utilizados como Value Objects, sem identidade, mas anda impede que se instancie outros (a menos que estejamos falando de coisas diferentes).

verdade, tinha esquecido deste detalhe

Notícias, artigos e o maior fórum brasileiro sobre Java