[quote=x@ndy]
PS: Uma coisa que tem que ficar clara é que enumeradores não foram feitos para serem usados como Singletons. Eles são usados por conveniência devido a problemas de segurança e a acesso por theads! Eu, como já comentei, acho estranho até o uso para isso e num mundo ideal com certeza não usaria enumeradores para criar singletons![/quote]
então vc precisa ler o Effective Java. Não usar enum é puro suicídio.
Enum foram feitos com uma serie de salvaguardas porque cada instancia do enum tem que ser única (Shared Object). Pro exemplo se vc serializar e desserializr o enum e der == vai dar true. Isto porque a JVM garante esta únicidade.
Mas esta unicidade é exactamente o que precisa para criar um singleton corretamente. O Enum não foi criado explicitamente para implementar singleton , mas é o artefacto tecnico melhor para realizar essa tarefa.
Obviamente o enum não tem que ser publico. Acho que é isso que está confundindo vcs. Mas é a forma mais segura, eficiente e pragmática de fazer. Então, porque fazer diferente ?
[quote=sergiotaborda][quote=x@ndy]
PS: Uma coisa que tem que ficar clara é que enumeradores não foram feitos para serem usados como Singletons. Eles são usados por conveniência devido a problemas de segurança e a acesso por theads! Eu, como já comentei, acho estranho até o uso para isso e num mundo ideal com certeza não usaria enumeradores para criar singletons![/quote]
então vc precisa ler o Effective Java. Não usar enum é puro suicídio.
Enum foram feitos com uma serie de salvaguardas porque cada instancia do enum tem que ser única (Shared Object). Pro exemplo se vc serializar e desserializr o enum e der == vai dar true. Isto porque a JVM garante esta únicidade.
Mas esta unicidade é exactamente o que precisa para criar um singleton corretamente. O Enum não foi criado explicitamente para implementar singleton , mas é o artefacto tecnico melhor para realizar essa tarefa.
Obviamente o enum não tem que ser publico. Acho que é isso que está confundindo vcs. Mas é a forma mais segura, eficiente e pragmática de fazer. Então, porque fazer diferente ?[/quote]
Foi justamente lendo esse livro que passei a usar enums como singleton.
[quote=sergiotaborda][quote=x@ndy]
PS: Uma coisa que tem que ficar clara é que enumeradores não foram feitos para serem usados como Singletons. Eles são usados por conveniência devido a problemas de segurança e a acesso por theads! Eu, como já comentei, acho estranho até o uso para isso e num mundo ideal com certeza não usaria enumeradores para criar singletons![/quote]
então vc precisa ler o Effective Java. Não usar enum é puro suicídio.
Enum foram feitos com uma serie de salvaguardas porque cada instancia do enum tem que ser única (Shared Object). Pro exemplo se vc serializar e desserializr o enum e der == vai dar true. Isto porque a JVM garante esta únicidade.
Mas esta unicidade é exactamente o que precisa para criar um singleton corretamente. O Enum não foi criado explicitamente para implementar singleton , mas é o artefacto tecnico melhor para realizar essa tarefa.
Obviamente o enum não tem que ser publico. Acho que é isso que está confundindo vcs. Mas é a forma mais segura, eficiente e pragmática de fazer. Então, porque fazer diferente ?[/quote]
Sergio, e li o Efective Java (e recomendo que todo mundo leia) mas acho que você não entendeu a minha colocação!
Estou dizendo que enum foi criado para ser um enumerador como em qualquer outra linguagem, mas mais ‘evoluído’ por assim dizer! Enumeradores era algo que linguagem deveria ter desde o inicio e sua falta criou uma série de problemas com o uso de constantes, fato que o Joshua aborda no Efective Java!
Só que enumeradores não foram feitos pensando no problema do padrão singleton no java! Essa não é sua principal finalidade e isso tem que ficar claro! O uso de enum para implementar um singleton é uma casualidade! Seu uso se deve justamente pelo que tu colocaste acima, pois se fosse seguro e simples usar singletons em java sem enum, através da implementação de uma classe, essa seria a melhor opção. Mas o mundo não perfeito e java não é perfeito então usar enum para implementar um singleton é um mal necessário!
[quote=x@ndy][quote=sergiotaborda][quote=x@ndy]
PS: Uma coisa que tem que ficar clara é que enumeradores não foram feitos para serem usados como Singletons. Eles são usados por conveniência devido a problemas de segurança e a acesso por theads! Eu, como já comentei, acho estranho até o uso para isso e num mundo ideal com certeza não usaria enumeradores para criar singletons![/quote]
então vc precisa ler o Effective Java. Não usar enum é puro suicídio.
Enum foram feitos com uma serie de salvaguardas porque cada instancia do enum tem que ser única (Shared Object). Pro exemplo se vc serializar e desserializr o enum e der == vai dar true. Isto porque a JVM garante esta únicidade.
Mas esta unicidade é exactamente o que precisa para criar um singleton corretamente. O Enum não foi criado explicitamente para implementar singleton , mas é o artefacto tecnico melhor para realizar essa tarefa.
Obviamente o enum não tem que ser publico. Acho que é isso que está confundindo vcs. Mas é a forma mais segura, eficiente e pragmática de fazer. Então, porque fazer diferente ?[/quote]
Sergio, e li o Efective Java (e recomendo que todo mundo leia) mas acho que você não entendeu a minha colocação!
Estou dizendo que enum foi criado para ser um enumerador como em qualquer outra linguagem, mas mais ‘evoluído’ por assim dizer! Enumeradores era algo que linguagem deveria ter desde o inicio e sua falta criou uma série de problemas com o uso de constantes, fato que o Joshua aborda no Efective Java!
Só que enumeradores não foram feitos pensando no problema do padrão singleton no java! Essa não é sua principal finalidade e isso tem que ficar claro! O uso de enum para implementar um singleton é uma casualidade! Seu uso se deve justamente pelo que tu colocaste acima, pois se fosse seguro e simples usar singletons em java sem enum, através da implementação de uma classe, essa seria a melhor opção. Mas o mundo não perfeito e java não é perfeito então usar enum para implementar um singleton é um mal necessário! [/quote]
Eu não chamaria de mal não. Chamaria de “solução bem colocada”.
Como programar em c++ e precisar de uma função para resolver determinados tipos de problemas. No java se usaria uma “classe helper”, mas em c++ esse conceito cai por terra porque “se você escreve uma classe para apenas prover uma função, você não precisa da classe em si, mas de uma função top level”.
Aí vem aquele monte de críticas dizendo sobre conceitos OO etc… Mas o top Level é a melhor solução nesse caso.
Isso realmente é um problema! Só que é dificil para quem está iniciando se aprofundar na linguagem e somente depois apreender os padrões! Acredito que os métodos de ensino deveriam começar a ensinar utilizando padrões! Quando alguém fosse falar de métodos e campos estáticos, por exemplo, poderia usa os padrões Factory Method e o próprio Singleton para isso! Estou justamente pensando em escrever um livro de introdução a java abordando esses aspectos, mas falta tempo.
[quote=sergiotaborda]
Não ha problema nenhum em uma enumeração só ter um elemento (conjunto singular). Aliás essa é a definição do que significa ser singleton ( único no conjunto)[/quote]
Aqui tu pegou pesado Sergio Com certeza não existe problema em ter um enum com unico elemento (tirando o fato de ser estranho) mas um singleton é único no conjunto de objetos da aplicação e não do de itens do Enum. Tanto que posso ter um enum com varios itens os quais serão sempre únicos no contexto da aplicação
É isso que estou colocando como mal necessário! Para mim as funções top level também entram nesse quesito, pois é mais simples, fácil e eficiente embora não seja o ideal! Como disse não existe linguagem perfeita e nem paradigmas perfeitos, então é muitas vezes temos que contornar os problemas da melhor forma
Com certeza não existe problema em ter um enum com unico elemento (tirando o fato de ser estranho) mas um singleton é único no conjunto de objetos da aplicação e não do de itens do Enum. Tanto que posso ter um enum com varios itens os quais serão sempre únicos no contexto da aplicação 