Dúvidas Sobre O Incompreendido Singleton

Depois de mt estudar sobre Singleton, cheguei à conclusão que este é o padrão mais incompreendido da história. Segundo a maioria das definições, um Singleton somente permite uma única instância de um objeto. Certo, se eu tenho por exemplo um programa feito em C++, e eu criei uma classe para gerenciamento de conexão com banco de dados onde um singleton me retorna uma instância de um objeto (fictício) “Connection”. Se eu tiver apenas uma única instância do programa rodando, eu tenho um singleton do objeto “Connection”.

Mas e se eu executo o mesmo programa várias vezes? Várias instâncias de “Connection” seriam criadas, uma para cada programa executado!

Afinal, o Singleton tem relação num CONTEXTO GERAL (onde eu tenho somente 1 único objeto, mesmo para várias aplicações), ou num CONTEXTO LOCAL (de um programa somente)?

Normalmente um “singleton” é fácil de implementar usando a definição “um singleton por processo” e difícil de implementar se usarmos a definição “um singleton por máquina” ou pior, “um singleton por sistema”.

E é por isso que normalmente quando alguém lhe sugere usar um singleton está pensando em “um singleton por processo”.

No java vc tem um singleton por classloader :twisted:

O Singleton é necessário quando é imperativo que um determinado objeto exista uma e somente uma vez. Não é o caso de uma conexão ao banco. Se eu quiser, eu crio vários e o sistema não fica inconsistente por isso.

A verdade é: padrões de projeto são receitas escritas pela metade, somos nós os desenvolvedores que a concluímos de acordo com a necessidade. Se a instância precisa ser uma por processo, faremos. Se precisar ser uma por máquina ou uma por rede, também faremos. Nada disso descaracteriza o pattern Singleton.

Agora, usar Singleton quando não há necessidade é mais feio que bater na mãe.

Mt se fala do Singleton, mas a maioria dos comentários é sobre qdo NÃO USAR, ora, o negócio parece ter mais contras q prós. Vamos por o Singleton “na fogueira” então:

*) Qdo eu preciso ter somente um objeto de um certo tipo num programa qualquer, esse deve ser um Singleton ou não (digo isso por q em tese eu poderia não querer mais de um objeto desses, ou por economia de memória ou por outra razão qualquer);
*) Um ponto de acesso global ao objeto QUE SOMENTE POR SER 1;

Se colocarmos a questão de acesso global, eu não precisaria fazer “todo esse auê” com “getInstance()” e construtor privado, eu poderia criar um Registry com um objeto instanciado, e em toda parte do programa eu usaria esse mesmo para ter acesso aos métodos da classe.

Enfim, parece q o Singleton tem “mais utilidade” num projeto de biblioteca ou programa compartilhado. Num programa q só um programador fez (ou uma equipe q seja), quem vai ficar instanciando mts vezes o mesmo objeto, isso parece ser meio IRRACIONAL. Pensando assim, cai naquele negócio, é bem mais fácil então eu usar variável global pronto e acabou!

Comentem

O problema que eu vejo no singleton é justamente o famoso ‘getInstance()’.
Acho que fica muito menos problematico se o objeto cliente recebe o singleton por injeção de dependências, nesse caso o cliente nem precisa saber que aquela classe é um singleton. E se você usar algum conteiner de DI, esse controle pode ficar por conta do container

[quote=kompiler]Mt se fala do Singleton, mas a maioria dos comentários é sobre qdo NÃO USAR, ora, o negócio parece ter mais contras q prós. Vamos por o Singleton “na fogueira” então:

*) Qdo eu preciso ter somente um objeto de um certo tipo num programa qualquer, esse deve ser um Singleton ou não (digo isso por q em tese eu poderia não querer mais de um objeto desses, ou por economia de memória ou por outra razão qualquer);
*) Um ponto de acesso global ao objeto QUE SOMENTE POR SER 1;

Se colocarmos a questão de acesso global, eu não precisaria fazer “todo esse auê” com “getInstance()” e construtor privado, eu poderia criar um Registry com um objeto instanciado, e em toda parte do programa eu usaria esse mesmo para ter acesso aos métodos da classe.

Enfim, parece q o Singleton tem “mais utilidade” num projeto de biblioteca ou programa compartilhado. Num programa q só um programador fez (ou uma equipe q seja), quem vai ficar instanciando mts vezes o mesmo objeto, isso parece ser meio IRRACIONAL. Pensando assim, cai naquele negócio, é bem mais fácil então eu usar variável global pronto e acabou!

Comentem[/quote]

Exatamente, existem mais contras do que prós.

Singleton só é pra ser usado quando, ao criar um segundo objeto da mesma classe, poderia dar pau. Exemplo: imagine uma classe ModemCelular que é baseado num modem real conectado ao computador. Ora, não é possivel instanciar duis objetos ModemCelular porque não tem dois modems no computador. Então, eu restrinjo usando um Singleton.

Singeton é apenas pro caso de criar uma segunda instância é erro de execução. É mais comum praquelas classes que se baseadas em dispositivos de Hardware.

Usar singleton pra economizar memória é burrice. Você tem gigas! Acesso global é normal pra objetos, mas se usa um Registry de verdade, como o oferecido pelo JNDI ou pelo Spring.

Vou dar um exemplo do uso de um Singleton, temos o sistema, e ele fica no SysTray da maquina, existe um Singleton que rege o Sistema, e é responsavel pelo Tray e por matar o sistema.

Se o sistema pudesse ter mais do que um desses por aplicação poderiamos ter varios sistemas abertos em uma unica instancia, ou quando se fecha o frame Principal, a aplicação morresse ao invez de ser escondida.