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
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…
Quantas instâncias de out você tem?[/quote]
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[/quote]
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 
Quantas instâncias de out você tem?[/quote]
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[/quote]
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 :)[/quote]
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!
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… 
O Singleton por si só já é uma gambiarra…[/quote]
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.
O Singleton por si só já é uma gambiarra…[/quote]
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.[/quote]
Ok, então me mostre um exemplo da aplicação de um singleton.
[quote=wariows][quote=sergiotaborda]
Dizer que Singleton é gambiarra é falso e pior que isso, irresponsável.[/quote]
Ok, então me mostre um exemplo da aplicação de um singleton.[/quote]
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ó).
[quote=sergiotaborda][quote=wariows][quote=sergiotaborda]
Dizer que Singleton é gambiarra é falso e pior que isso, irresponsável.[/quote]
Ok, então me mostre um exemplo da aplicação de um singleton.[/quote]
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ó).
[/quote]
Ser o mesmo é diferente de ser um só. Se você utilizar um sistema distribuído, provavelmente não será nem o mesmo, nem único.
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
[quote=wariows][quote=sergiotaborda][quote=wariows][quote=sergiotaborda]
Dizer que Singleton é gambiarra é falso e pior que isso, irresponsável.[/quote]
Ok, então me mostre um exemplo da aplicação de um singleton.[/quote]
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ó).
[/quote]
Ser o mesmo é diferente de ser um só. Se você utilizar um sistema distribuído, provavelmente não será nem o mesmo, nem único.[/quote]
Exatamente por isso mesmo que o @Singleton do EJB ( que é um ambiente distribuido) não é uma implementação do padrão Singleton
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.