Vivendo e aprendendo. Agora o Taborda abriu uma questão interessante sobre a confusão entre shared-objects e singletons. Eu mesmo tinha essa confusão na minha mente de que singleton é apenas para ter uma instância única.
[quote]A diferença entre um shared e um singleton é que o shared usa uma única instancia por escolha. Ele escolhe pegar um objeto qualquer e só instanciá-lo uma vez. Não importa se o objeto pode ser instanciado mais vezes, ele só o faz uma vez.
O singleton só cria uma unica instancia porque só uma é possivel. Mesmo que eu queira criar outra eu não vou conseguir. Não importa quem está usando o objecto , nem porque, o mecanismo de criação estão armadilhado para que apenas uma instancia seja possivel de ser criada. [/quote]
[quote=peczenyj]Em que condições os singletons são interessantes?
Imagino que em ambientes com restrições de memória e uma unica instância de jvm eu posso querer usar singletons, mas por economia. Ou não?[/quote]
singletons não são trade-offs. Vc não escolhe fazer uma classe singleton ou não singleton. O uso do padrão Singleton é uma necessidade, não uma escolha.
O exemplo claro é Runtime e Desktop. Quantos runtimes existem em um programa ? 1. Apenas 1. Nunca mais que 1. Portanto esse cara tem ser singleton. Não faz sentido lógico que exista mais do que um objeto runtime. É decisão abstrata de SoC. Não é uma decisao de implementação. Não é um trade-off.
Desktop. quantos desktop podem existir num OS ? 0 ou 1. Nunca mais que 1. Se o OS não suporta o conceito é zero. Dekstop.getDesktop dá exception. Se o OS suporta, o objeto é criado e devolvido.
outro exemplo : SystemTray. Quantos systemTrays podem existir. 1. apenas 1.
singletons não são “interessantes” são necessários e obrigatórios. Se para uma classe X qq vc poder implementar de outra forma que não um singleton, então essa classe não é um singleton e vc não deve usar o padrão Singleton. Tão simples assim.
Vou te ensinar um truque legal, creio entao que voce nao conheca:
Constructor<Desktop> c = ReflectionFactory.getReflectionFactory().newConstructorForSerialization(Desktop.class, Object.class.getDeclaredConstructor(new Class[0]));
Desktop d1 = (Desktop) c.newInstance();
Desktop d2 = Desktop.getDesktop();
if (d1 != d2) {
System.out.println("O que o Taborda disse que não da para fazer, da sim para fazer e é bem facil.");
} else {
System.out.println("O que o Taborda disse que não da para fazer, realmente nao da.");
}
Aprendi enquanto estudava os commits do meu irmao no XStream ha alguns anos atras. Vale a pena voce dar uma estudada tambem, da para setar campos final depois, etc etc. Fica ai a dica para voce.
Como eu já disse anteriormente, por magia negra + reflection da pra fazer (e em qualquer VM, cada uma no seu modo).
Sergio, como ficamos entao com sua implementacao de Singleton? Ela é invalida tambem? Nao existem singletons entao? Nem factories? ja que da tudo para burlar com esses truques? Seria o Desktop uma implementacao mal feita de singleton, ja que acabo de mostrar que posso instancia-lo a vontade?
O Padrão Singleton pode ser modificado para que exista “um número máximo de instâncias de uma classe”, caracterizando assim um pool de objetos, flexibilizando seu emprego nas situações em que não é necessário garantir uma instância única, mas onde deve ser limitada a quantidade total de objetos e recursos utilizados.
[quote=Paulo Silveira][quote=sergiotaborda]
Algumas pessoas falam que reflection estraga o padrão singleton. Tente usar reflection para criar uma instancia de Runtime ou Desktop.
[/quote]
Vou te ensinar um truque legal (…)
[/quote]
[quote=javadoc de sun.reflect.ReflectionFactory]
The master factory for all reflective objects, both those in java.lang.reflect (Fields, Methods, Constructors) as well as their delegates (FieldAccessors, MethodAccessors, ConstructorAccessors).
The methods in this class are extremely unsafe and can cause subversion of both the language and the verifier. For this reason, they are all instance methods, and access to the constructor of this factory is guarded by a security check, in similar style to sun.misc.Unsafe . [/quote]
Isso não é reflection:
Não está no pacote java.lang nem java.lang.reflect.
Não é portável. Só funciona na jvm da sun.
Vc já deveria saber a esta hora que não se devem usar classes do pacote sun.*
Essa é uma operação nao segura.
Essa resposta é inválida. Não responde ao desafio. O desafio era usar reflection. Vc não usou reflection. Use algo no pacote java.* e voltamos ao assunto.
Essas coisas do tipo, patterns, smell e tantas outras coisas são um mal danado pra essa comunidade. O pior é que acaba enjaulando alguns - se você ousa ser um pouco criativo e fazer uma alteração/experimento em alguma idéia ou pattern para ganhar produtividade já vem neguinho apontar o dedo dizendo que você não sabe OO e tem que estudar mais. Aff… isso é exagero.
Na maioria dos casos pattern só adiciona complexidade e burocracia. Faz do jeito mais prático e pronto
[quote=ccaneta]O Padrão Singleton pode ser modificado para que exista “um número máximo de instâncias de uma classe”, caracterizando assim um pool de objetos,
[/quote]
Não. Isso é conceptualmente errado. Singleton não um master-pattern de onde derivam os outros.
Se vc quer poder escolher quantas instancias ha , isso não é um singleton. nem um shared object, é ,como vc falou , um pool. mais concretamente ObjectPool.
[quote=Thiago Senna]Essas coisas do tipo, patterns, smell e tantas outras coisas são um mal danado pra essa comunidade. O pior é que acaba enjaulando alguns - se você ousa ser um pouco criativo e fazer uma alteração/experimento em alguma idéia ou pattern para ganhar produtividade já vem neguinho apontar o dedo dizendo que você não sabe OO e tem que estudar mais. Aff… isso é exagero.
Na maioria dos casos pattern só adiciona complexidade e burocracia. Faz do jeito mais prático e pronto ;)[/quote]
-static instance:Singleton
+static getInstance():Singleton--------------------return instance
[quote=Thiago Senna]Essas coisas do tipo, patterns, smell e tantas outras coisas são um mal danado pra essa comunidade. O pior é que acaba enjaulando alguns - se você ousa ser um pouco criativo e fazer uma alteração/experimento em alguma idéia ou pattern para ganhar produtividade já vem neguinho apontar o dedo dizendo que você não sabe OO e tem que estudar mais. Aff… isso é exagero.
Na maioria dos casos pattern só adiciona complexidade e burocracia. Faz do jeito mais prático e pronto ;)[/quote]
Mais prático não significa mais desleixado. Mais simples, não significa mais fácil.
Se vc não quer usar o padrão , blz. Mas o padrão é aceite universalmente. se vc tem uma ideia melhor, vc tem que defendê-la corretamente. apenas invocar criatividade não vale. A razão é que quem faz gamb tb invoca a criatividade.
Tem gente que não enxerga um palmo à frente do nariz, é verdade. Mas esses não são bons designers. SE o cara não quer que vc mude algo, ele tb tem que dar argumentos.
Pattern não adiciona burocracia. Isso é uma falácia.
O que adiciona burocracia é o mau uso dos patterns. más práticas OO, mau entendimento dos principios, etc…
não culpe os patterns pela burrice dos designers ou pseudo-designers.
Padrões são boms sim, e deviam ser até mais difundidos. Evitaria muito ré-trabalho e ré-dor-de-cabeça.
O difícil é enteldê-los na essência a ponto de utilizá-los com consistência.
Singleton é ruin depende de quem usa.
Eu peguei um projeto Mobile onde o tudo era Singleton - para diminuir o consumo de recursos (tenha paciência).
Porém em alguns locais uso singleton e não tenho problema nenhum.
Mas também não concordo no “Desenvolvimento Orientado a Padrões”, onde sem saber se é necessário, utilizar logo o padrão de cara.
Lendo o livro Refatoração Para Padrões, é possível ver que a melhor forma de aplicar um padrão é quando o problem já existe, e você usa o padrão para resolver - e não criar o problema para resolver com um padrão.
[quote=sergiotaborda][quote=ccaneta]O Padrão Singleton pode ser modificado para que exista “um número máximo de instâncias de uma classe”, caracterizando assim um pool de objetos,
[/quote]
Não. Isso é conceptualmente errado. Singleton não um master-pattern de onde derivam os outros.
Se vc quer poder escolher quantas instancias ha , isso não é um singleton. nem um shared object, é ,como vc falou , um pool. mais concretamente ObjectPool.
Não existe isso de “modificar padrões”.[/quote]
“i Permits a variable number of instances. The pattern makes it easy to change your mind and allow more than one instance of the Singleton class. Moreover, you can use the same approach to control the number of insntaces that the application uses.[/i]”
Erich Gamma at Al, Design Patterns, pagina 128. Leitura recomendada!
É bom sustentarmos nossas afirmações com referencias, para que a discussão não se torne meramente opinativa!
Porque?
Eu confio na minha capacidade e modifico se necessário.
A final de contas, padrões não são perfeitos.
Vamos virar a cabeça pros lados e enxergar possibilidades e não usar sempre os pré-moldados ein?
E padrões adicionam complexidade sim, o prório GoF diz isso.
Você pode até conhecer os padões, mas e seus programadores?
E os coitados dos estagiários? Não fazem parte da sua equipe? Ou você é uma EUquipe?
[quote=sergiotaborda]Pattern não adiciona burocracia. Isso é uma falácia.
…
padrões não adicionam complexidade
[/quote]
Poxa! Outra negação do que esta no livro seminal! O xdraculax está coberto de razão:
Often they (design patterns) achieve flexibility and variability by introducing additional levels of indirection, and then can complicate a design
Design Patterns, página 31!!!
Voce teria alguma referencia sobre patterns nao adicionarem complexidade? Acho que precisamos de mais referencias para isso aqui nao virar conversa de bar, onde so ha opinioes.
[quote=Paulo Silveira]“i Permits a variable number of instances. The pattern makes it easy to change your mind and allow more than one instance of the Singleton class. Moreover, you can use the same approach to control the number of insntaces that the application uses.[/i]”
Erich Gamma at Al, Design Patterns, pagina 128. Leitura recomendada!
[/quote]
Perai, vc está citando e recomendando o mesmo livro que este topico começa por dizer que está desatualizado ?! :shock:
[quote]
É bom sustentarmos nossas afirmações com referencias, para que a discussão não se torne meramente opinativa![/quote]
Quem acha que padrões é ruim , é coisa do demo, que programar com padrões é pior que programar ad doc, que saber padrões é desperdicio de tempo e de espaço, por favor pare de usar padrões. Esqueça que existem. Mas deixe o seu contacto no codigo para que o programador que vem a seguir poder procurar vc para explicações.
Falar que padrões é ruim é muito fácil. porque não dizer também que os principios de OO são ruins ? Afinal eles são mal usados o tempo todo. Os mesmos argumentos podem ser usados com qualquer coisa , prática ou teorica , que as massas de programador usam mal.
O ponto é muito simples : quem usa mal não pode dizer que o problema é do padrão/tecnica/prática/etc… o problema é do programador/equipe que desenhou a porcaria do código totalmente sem noção.
Essa frase está dizendo o que é possível: The pattern makes it easy to change your mind and allow more than one instance of the Singleton class. Moreover, you can use the same approach to control the number of insntaces that the application uses."
Mas em momento nenhum ela afirma que o resultado disso ainda é um singleton. Ou afirma?
Essa frase está dizendo o que é possível: The pattern makes it easy to change your mind and allow more than one instance of the Singleton class. Moreover, you can use the same approach to control the number of insntaces that the application uses."
Mas em momento nenhum ela afirma que o resultado disso ainda é um singleton. Ou afirma?[/quote]
Tem razao!. Nao afirma, e nao é mesmo. É um shared object ou pool, dependendo. Ou ainda um factory method. Mas mostra que o pattern pode ir sofrendo alteracoes (rra essa a questao)
Engraçado, a definição original do pattern singleton diz: Ensure a class only has one instance, and provide a global point of access to it. [P. 127, edição de 1996 americana]
De cara, na definição, ele não fala em permitir a criação de uma única instância, embora seja um pattern criacional, mas em ter apenas uma única instância por vez. Ou seja, o singleton poderia ser destruido e recriado e, embora isso seja trabalhoso em Java, seria plenamente possível em linguagens não gerenciadas.
E notem que na definição original também cita o fato do singleton ser um “Global access point”. Entretanto, vale frisar que ser um Global access point não é o mesmo que dizer que o singleton deveria ser uma “variável global”.
Realmente, o livro deveria ser revisado porque a definição como está, leva ao erro.
