Singleton - Parametros

31 respostas
M

Galera… preciso passar um Parametro para dentro de um SINGLETON

Alguem tem alguma ideia de como fazer isso… fiz alguns testes aqui sem sucesso…

Vlws…

31 Respostas

fiaux

Como assim?

wariows

http://steve.yegge.googlepages.com/singleton-considered-stupid

Hoje em dia, Singleton é considerado um anti-pattern, ou seja, uma má solução para o seu problema. Tem vários tópicos aqui no fórum falando sobre isso… Dá uma lida!

[]´s

wariows

QUARENTA DOIS!

peczenyj

No aguardo de uma anotação @Singleton para evitar as 1024 gambiarras que são necessárias para ter um singleton em Java :slight_smile:

wariows

O Singleton por si só já é uma gambiarra…

peczenyj

O Singleton por si só já é uma gambiarra…

Não necessariamente :twisted:

System.out que o diga :slight_smile:

wariows

O Singleton por si só já é uma gambiarra…

Não necessariamente :twisted:

System.out que o diga :)

System não é um Singleton!!

Definição de singleton:

Acessar métodos estáticos de uma classe não leva ele a ser um Singleton!

tnaires

Ele estava falando do objeto out.

Rafael_Nunes

Mas a classe ‘System’ não é um Singleton, você só não pode criar uma instância dela.
E ‘out’ é só um atributo estático da classe que representa um PrintStream.

Ou eu quem não entendi o que você quis dizer?

Rafael_Nunes

Ele estava falando do objeto out.

É só um atributo estático do tipo PrintStream.

wariows

Ele estava falando do objeto out.

Isto serve para atributos static também…

wariows

Ele estava falando do objeto out.

É só um atributo estático do tipo PrintStream.

Nesse cara eu boto fé.

tnaires

Acho que o que o peczenyj quis dizer é que você só tem um objeto out.

wariows

Quantas instâncias de out você tem?

Primeiramente out não é uma Classe, então eu não posso ter instâncias de out. Alem disso, out é uma instância de PrintStream, e dessa classe eu posso ter quantas instâncias eu quiser… Logo, não tem Singleton nenhum nessa história.

http://java.sun.com/j2se/1.5.0/docs/api/java/io/PrintStream.html

tnaires

Me expressei errado, editei meu post pra indicar o que eu queria de fato dizer.

wariows
String essaEhAMinhaStringEscabrosaDoMalDoGujQueVouUsarNumTopicoSobreSingleton = new String("aaaaa");

Quantos objetos essaEhAMinhaStringEscabrosaDoMalDoGujQueVouUsarNumTopicoSobreSingleton eu tenho aí? Vocês estão fazendo uma comparação à nível de Classe em uma instância dela… De PrintStream eu posso ter inúmeras instâncias…

tnaires

Tudo bem cara, deixa pra lá.
Já entendi que estou errado. Além disso, essa discussão nem minha é, só estava tentando fazer você entender o argumento do peczenyj.

M

Certinho galera… mas qual seria uma boa solucao para uma classe que tem ser executada apenas uma vez para a sessao do usuario e que possa receber um parametro???

Vlws…

wariows

mrmbrasileiro:
Certinho galera… mas qual seria uma boa solucao para uma classe que tem ser executada apenas uma vez para a sessao do usuario e que possa receber um parametro???

Vlws…

Explica melhor o que tu quer fazer, pra gente poder entrar no contexto.

M

Eh que estou desenvolvendo um framework e estou na parte de criacao do menu…
entaum pensei em criar um objeto q monte o menu um unica vez na sessao do usuario (reduzindo os acessos ao banco de dados)…
primeiramente pensei num singleton ou numa factory… mas com o singleton naum consegui passar o usuarioi por parametro mas a checagem de permissoes para montagem do menu…
espero ter sido mais claro agora…

[]'s

wariows

Põe uma Map<Usuario,Sessao ou Menu (Não sei como é sua associação)> como atributo de classe:

public MinhaClasse {
   private static Map<Usuario,Sessao> map;
}

Daí você verifica se já foi montado o menu ou não… depende da lógica que você quiser…

Mas esse modo que eu te falei, garante que para qualquer instância de MinhaClasse, a instância de Map seja a mesma…
Acho que precisa de um synchronized ali…

[]´s

Editado: Se bem que acho que você não precisa disso… É preciso ver melhor o método como vc cria os menus pra dizer uma boa solução… Mas se você realmente precisar acessar a mesma instância pra saber o menu já foi montado ou não, a solução que eu falei deve funcionar…

peczenyj

Quantas instâncias de out você tem?

Primeiramente out não é uma Classe, então eu não posso ter instâncias de out. Alem disso, out é uma instância de PrintStream, e dessa classe eu posso ter quantas instâncias eu quiser… Logo, não tem Singleton nenhum nessa história.

http://java.sun.com/j2se/1.5.0/docs/api/java/io/PrintStream.html

Na pratica é a mesma coisa, vc tem um ponto de acesso comum a um objeto e eu não tenho 2 instâncias diferentes de out zanzando por ai :slight_smile:

wariows

Quantas instâncias de out você tem?

Primeiramente out não é uma Classe, então eu não posso ter instâncias de out. Alem disso, out é uma instância de PrintStream, e dessa classe eu posso ter quantas instâncias eu quiser… Logo, não tem Singleton nenhum nessa história.

http://java.sun.com/j2se/1.5.0/docs/api/java/io/PrintStream.html

Na pratica é a mesma coisa, vc tem um ponto de acesso comum a um objeto e eu não tenho 2 instâncias diferentes de out zanzando por ai :)

A questão não é ser a mesma coisa na prática, a diferença é conceitual… Uma coisa é garantir que seja a MESMA instância, a outra é garantir que só exista UMA instância… Se um PrintStream fosse um singleton, eu não poderia ter minhas instâncias de PrintStream… e eu posso!

Rafael_Nunes

Se for partir deste princípio, todo e qualquer atributo estático é um Singleton.

E também esse ‘out’ é criado nativamente, então você não tem como garantir que será sempre o mesmo… :wink:

sergiotaborda

O Singleton por si só já é uma gambiarra…

Mas que confusão… será que eu serei vivo no dia em que as pessoas entenderem o padrão singleton ?

peczeny , a anotação @Singleton da próxima versão EJB não cria realmente um singleton. Ele cria um Shared Object (objeto partilhado). A especificação garante que as informações está localizados num unico objeto, mas não garante que ele é único.
Para começo de conversa o objeto pode ser distribuído em JVM diferentes para efeitos de clustering o que por definição viola o padrão singleton ( garantir que uma classe tem um e um só objeto instanciando a qualquer instance).
Mesmo na mesma JVM e no mesmo container o container é livre de matar e instanciar o objeto como quiser e quando quiser e no numero de objetos que quiser. Ela só tem que garantir que o estado do objeto seja o mesmo.
Infelizmente a propria Sun caiu no engôdo de chamar singleton aos shared Object… é triste e temos que viver com isso, mas isso não significa que temos que ter o conceito errado.

wariows, é dificil de aceitar que um padrão possa ser uma gambiarra. Se fosse, não seria um padrão.
Dizer que o singleton é um anti-pattern tb é um exagero porque nenhuma (quase nenhuma) aplicação real usa o padrão singleton. Lembre-se que o singleton é padrão GoF que escreveu padrão para C++. Em C++ faz sentido ter um singleton quando se trabalha com recursos escassos dos sistema ou de hardware. Em java que realmente se usa é shared object ou Factory e é - erradamente - chamado de singleton. Isso implementa variáveis globais que quando não são bem usadas podem ser um problema. Existem outros padrões melhores para objetos globais como Register e o proprio Shared Objet que mencionei antes ( é por shared ser melhor que singleton que o @Singleton é na realdiade um shared)

Dizer que Singleton é gambiarra é falso e pior que isso, irresponsável.

wariows

O Singleton por si só já é uma gambiarra…

Mas que confusão… será que eu serei vivo no dia em que as pessoas entenderem o padrão singleton ?

peczeny , a anotação @Singleton da próxima versão EJB não cria realmente um singleton. Ele cria um Shared Object (objeto partilhado). A especificação garante que as informações está localizados num unico objeto, mas não garante que ele é único.
Para começo de conversa o objeto pode ser distribuído em JVM diferentes para efeitos de clustering o que por definição viola o padrão singleton ( garantir que uma classe tem um e um só objeto instanciando a qualquer instance).
Mesmo na mesma JVM e no mesmo container o container é livre de matar e instanciar o objeto como quiser e quando quiser e no numero de objetos que quiser. Ela só tem que garantir que o estado do objeto seja o mesmo.
Infelizmente a propria Sun caiu no engôdo de chamar singleton aos shared Object… é triste e temos que viver com isso, mas isso não significa que temos que ter o conceito errado.

wariows, é dificil de aceitar que um padrão possa ser uma gambiarra. Se fosse, não seria um padrão.
Dizer que o singleton é um anti-pattern tb é um exagero porque nenhuma (quase nenhuma) aplicação real usa o padrão singleton. Lembre-se que o singleton é padrão GoF que escreveu padrão para C++. Em C++ faz sentido ter um singleton quando se trabalha com recursos escassos dos sistema ou de hardware. Em java que realmente se usa é shared object ou Factory e é - erradamente - chamado de singleton. Isso implementa variáveis globais que quando não são bem usadas podem ser um problema. Existem outros padrões melhores para objetos globais como Register e o proprio Shared Objet que mencionei antes ( é por shared ser melhor que singleton que o @Singleton é na realdiade um shared)

Dizer que Singleton é gambiarra é falso e pior que isso, irresponsável.

Ok, então me mostre um exemplo da aplicação de um singleton.

sergiotaborda

wariows:
sergiotaborda:

Dizer que Singleton é gambiarra é falso e pior que isso, irresponsável.

Ok, então me mostre um exemplo da aplicação de um singleton.

java.awt.Desktop

Desktop é um recurso do sistema ( que pode nem existir) que é único. Não faz sentido ter vários objetos Desktop porque só ha um Desktop ( ou seja, se existisse vários objetos eles teriam que ser o mesmo, o que significa que seriam um objeto só).

wariows

sergiotaborda:
wariows:
sergiotaborda:

Dizer que Singleton é gambiarra é falso e pior que isso, irresponsável.

Ok, então me mostre um exemplo da aplicação de um singleton.

java.awt.Desktop

Desktop é um recurso do sistema ( que pode nem existir) que é único. Não faz sentido ter vários objetos Desktop porque só ha um Desktop ( ou seja, se existisse vários objetos eles teriam que ser o mesmo, o que significa que seriam um objeto só).

Ser o mesmo é diferente de ser um só. Se você utilizar um sistema distribuído, provavelmente não será nem o mesmo, nem único.

jgbt

Não teria sentido Singleton em um sistema distribuido, pois vc teria mais de uma JVM.

Singleton não é um anti-pattern se usado quando realmente necessario. É mesmo caso de VO’s/TO’s/DTO’s da vida, no cenario certo tem sua utilidade.
No cenario errado, são antipatterns. Com Singleton é a mesma coisa.
Cuidado com as verdades absolutas.

[]´s

sergiotaborda

wariows:
sergiotaborda:
wariows:
sergiotaborda:

Dizer que Singleton é gambiarra é falso e pior que isso, irresponsável.

Ok, então me mostre um exemplo da aplicação de um singleton.

java.awt.Desktop

Desktop é um recurso do sistema ( que pode nem existir) que é único. Não faz sentido ter vários objetos Desktop porque só ha um Desktop ( ou seja, se existisse vários objetos eles teriam que ser o mesmo, o que significa que seriam um objeto só).

Ser o mesmo é diferente de ser um só. Se você utilizar um sistema distribuído, provavelmente não será nem o mesmo, nem único.

Exatamente por isso mesmo que o @Singleton do EJB ( que é um ambiente distribuido) não é uma implementação do padrão Singleton

Abdon

Uma vez alguem aqui deste forum falou uma frase que eu gostei muito:

Em termos de negocio eu nunca vi a necessidade de um singleton o uso do mesmo esta mais relacionado com infra da app.

Criado 25 de setembro de 2008
Ultima resposta 26 de set. de 2008
Respostas 31
Participantes 9