Livro Design Patterns: e se houvesse uma segunda edição?

sergiotaborda wrote:...

Tirando as frases mais exaltadas, eu acho que no fim estamos todos falando a mesma coisa. Patterns são difíceis mas resolvem bem alguns problemas, e ótimos exemplos estão na própria API do Java SE.

E sobre o singleton em particular, é o que eu falei: o problema em geral não está em ter uma única instância (isso às vezes é útil, mas raramente como você disse). O problema é o acesso global vinculado ao Singleton (e aliás a alguns outros patterns creacionais, como a própria Factory).

Você sugeriu usar Registry para evitar o acesso global. Ok, é um jeito (embora eu não goste). Mas DI é outro jeito (que aliás substitui boa parte da necessidade do Registry). Hoje singleton acabou virando configuração dentro de container IoC, bem como boa parte das Factories, que fabricam para um container depois injetar (não chamamos mais factories em nossos códigos).

Aliás, também achei @Singleton uma má ideia

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

javamaniaco wrote:

sergiotaborda wrote:

Castigar o singleton pelo mau uso que os programadores fazem dele é como castigar a tinta pelas palavras groseiras que se escrevem com ela. Ainda mais absurdo é culpar todos os padrões como um todo. É como se castigássemos o próprio alfabeto por permitir escrever palavras.

Que raios deu em vocês ?

Palavras bonitas mas como de um político. Você fala para poucos e logo poucos lhe escutam.
Conheceu Rails? Viu Ruby? Quando colocamos a mão em situações como Ruby, Rails, questionamos o porque o Java ou outra louca linguagem que deseja seguir este método obscuro de desenvolvimento existe.

Isso porque vc tem pouca bagagem para entender. Qual é a base do modelo de objetos do ruby ? Em java é classe, em javascript é
prototype ( os dois são padrões ) e em ruby ? vc sabe ? eu lhe digo : meta-class.
O que é um meta-class ? é o uso do padrão MetaObject. Um MetaObject é um objeto que descreve outro. Este padrão é muito usado em XML onde um esquema define o xml, em banco de dados onde um conjunto de informações define os "metadados" (passo a expressão) do banco. Em java o tipo Class é um MetaObject porque define como um object será. Uma meta-class do ruby é um objeto que define como a class será. É um nivel acima. E é isso, apenas isso, que permite que o ruby seja mais flexivel que java. É facil entender porquê essa flexibilidade pois vc está usando um nivel de abstração mais elevado. O mesmo acontece com groovy e outras linguagens com meta-class.

Desde que comecei a aprender Java vi tantas palavras que posso colocar em um dicionário facilmente.

Vc não viu o suficiente. tinha visto o padrão MetaObject ?

Seria falta de conhecimento decoreba dos padrões?

Obviamente.

Sei não, pra mim é coçar a orelha esquerda com a mão direita.

Ha pessoas que dizem que furam, ha pessoa que obliteram. Cada um usa a palavra mais explicativa que conhece.

Ai vem um Rails da vida, mostra que, tudo que fiz poderia ser prático, divertido e nada confuso.

E veja só que interessante. Ele faz tudo isso apenas com um design pattern: MetaObject. Genial, não ?

Eu digo uma coisa, levei nem 1 mês para entender Rails, em 2 meses estava em um projeto e até hoje já passei por 4 projetos em Rails, sendo um de porte médio. Mudei de equipe várias e várias vezes e cada linha escrita e reescrita eu compreendo. Se entrar no meio de um projeto Rails já sou produtivo. Se for em Java, só se der sorte.

Na boa, que culpa tenho eu disso ? Que culpa tenho eu ou o java ou quem quer que seja, dos seus talentos e defeitos ?

Sorte com a complexidade ou com metidos arrogantes que arrotam letras e padrões que nunca ouvi falar, mas que existem talvez para tornar o programador mais valioso.

Mais uma vez : que culpa temos nós que vc não ouvi falar ? a culpa é toda sua que não estudou o suficiente!
Veja só que a ironia : vc está dizendo que ruby é uma maravilha, mas ele é feito a partir de um padrão chamado MetaObject que vc nunca ouviu falar. O cara que inventou o ruby, deve ser, portanto, pela sua logica um "metido arrogante".

Alguns fazem, alguns ensinam e o resto lê nos livros.
E algums nem livros leêm...

Culpar padrões ou o java ou a sun ou o jcp ou seja quem for pela própria ignorância é desonesto e irresponsável.

Eu não tenho culpa de saber padrões. Ou vão me queimar na fogueira por isso ?

This message was edited 1 time. Last update was at 27/10/2009 23:32:48

[editado por mim mesmo - estava redundante com o que o Sergio escreveu ]

... menos a parte de @Singleton. Qual mal vc vê nesta anotação Sergio Lopes? E você Taborda, que mal você vê em uma anotação que realmente provê a criação única de um objeto em memória? Somente o nome? Se for isso o que vc sugeriria, apenas por curiosidade.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

Sergio Lopes wrote:

Você sugeriu usar Registry para evitar o acesso global. Ok, é um jeito (embora eu não goste). Mas DI é outro jeito (que aliás substitui boa parte da necessidade do Registry).

Pois é... então vc acha que o Spring não tem um Registry... o que vc acha que é o ApplicationContext com o seu getBean(id) ?
Pense melhor.

No guice é mais obvio o uso de regestry no objeto de bind onde vc configura o bind da interface/classe com a classe.
Não é possivel trabalhar com metadados em um Registry. A razão é simples : metadados, são, por definição, globais.

Releia o conceito de Registry e compare com o ApplicationContext. Já agora compare tb o Factory com o Provider do Guice.

Motores de injeção precisa criar objetos : logo, precisão de saber como criá-los ( registry de metadados) , criá-los (factory) e depois injetá-los (Registry de metadados de injeção lidos de annotações, xml, etc... ) se o objeto tem mecanismos especiais de criação como singleton, prototype, etc... então é preciso um factory especial, mas um factory, non the less...

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

Alessandro Lazarotti wrote:Olã Sergio,
Não olhei o ponto onde alguém confundiu Singleton com DI. Como você mencionou Singleton é padrão criacional e de nada tem haver com DI. O que muitos disseram aqui (e não só aqui), é que em muitos casos você pode delegar a criação do objeto fora da classe que a tem como composta ou do método que a utiliza, diminuindo a amarração da classe, o que não ocorre na maioria das vezes que é utilizado Singleton.

O que estou dizendo é muito simples : não ha como delegar a criação de um singleton a uma outra classe. Essa é a essencia do padrão. Se vc delega, é porque, obviamente não era um singleton. Singletons verdadeiros não podem ser criados sem ser pela sua propria classe.

Veja bem o conceito de singleton nasce da proibição explicita de injeção de dependencia que é um principio da OO. Portanto, não faz sentido que um motor de injeção possa criar um singleton. É como ter uma fabrica de singleton, simplesmente impossivel.

O ponto que abordei é a confusão de que um singleton possa ser criado via motor de DI. Não pode. O exemplo é a classe Desktop.
Contudo, isso não signfiica que eu não o possa injetar. Posso sim. É só configurar o motor de DI corretamente. Isto rebate o que foi dito que não usar singleton aumenta a testabilidade e a injeção. Isso é falso. Vc nunca usa singleton porque quer. VC usa porque precisa. Se ha outro jeito então aquilo não era um singleton para começo de conversa.

Pense realmente a fundo num outro jeito de implementar Runtime ou Desktop sem ser usando singleton. Não é possivel. Venham quantos DI existirem...

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 718 Offline

sorry taborda, editei apagando o que vc quotou antes de ver sua resposta

sergiotaborda wrote:Pois é... então vc acha que o Spring não tem um Registry... o que vc acha que é o ApplicationContext com o seu getBean(id) ?

sergiotaborda wrote:Motores de injeção precisa criar objetos : logo, precisão de saber como criá-los ( registry de metadados) , criá-los (factory) e depois injetá-los (Registry de metadados de injeção lidos de annotações, xml, etc... ) se o objeto tem mecanismos especiais de criação como singleton, prototype, etc... então é preciso um factory especial, mas um factory, non the less...

Mas é justo esse o ponto! Esses patterns hoje estão dentro dos containers IoC, a gente não escreve mais essas coisas.

Aliás, ninguém chama o getBean no Spring diretamente, certo? Senão ele seria um Registrizão esperto, apenas isso (como voce mesmo disse).

This message was edited 1 time. Last update was at 27/10/2009 23:41:40

sergiotaborda wrote:
confundir singleton dom DI ? mas que raios vcs estão pensando ? Singleton é um padrão criacional !
Vc se esquecem que DI usa factories. Alguem tem que criar os objetos para eles serem injetados !! em todos os motores de DI vc pode configurar essas factories. O ponto não é injetar, mas sim criar. Se a classe ñ é singleton várias instancias podem ser criadas mesmo com um motor de DI.

Creio que todos estamos falando o mesmo: o pessoal costuma usar singleton erroneamente, por isso precisam ter cuidado, como o proprio Erich Gamma disse: I'm in favor of dropping Singleton. Its use is almost always a design smell. Da até pra ver isso nessa sua frase:

sergiotaborda wrote:
O que estou dizendo é muito simples : não ha como delegar a criação de um singleton a uma outra classe. Essa é a essencia do padrão. Se vc delega, é porque, obviamente não era um singleton.

Exatamente, mas é detalhe de nomeclatura para facilitar, todos estão falando a mesma coisa aqui. A maioria do pessoal queria um shared object, e não um singleton! (e muitas vezes é até questionável a necessidade de shared object).

Em nenhum momento dissemos que singleton esta sempre errado, ou que não se deve estudar Design Patterns, etc. Como você disse, devemos aprender a usa-los, mas direito.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

Alessandro Lazarotti wrote:[editado por mim mesmo - estava redundante com o que o Sergio escreveu ]

... menos a parte de @Singleton. Qual mal vc vê nesta anotação Sergio Lopes? E você Taborda, que mal você vê em uma anotação que realmente provê a criação única de um objeto em memória? Somente o nome? Se for isso o que vc sugeriria, apenas por curiosidade.

1) Essa anotaçao não proves a criação unica na memoria. Se eu quiser criar outro eu posso. É só dar new. Um verdadeiro singleton vc não tem sequer como controlar a criação. Vc não pode criar outro mesmo que queira.
Um objeto que é instanciado uma vez por escolha ( para poupar memoria por exemplo) é um Shared Object, não um Singleton. são padrões diferentes que servem para coisas diferentes. Exemplo , Integer tem charedobjects para numeros no range de byte, Locale e Currency e outros usam isso tb. É um padrão bem comum para minimizar a criação redundante de objetos.

2) dado o argumento anterior o nome é horrivel. Deveria ser @Shared. ou @Unique ou qq outro abdejetivo. Tods menos Singleton.

sergiotaborda wrote:Veja bem o conceito de singleton nasce da proibição explicita de injeção de dependencia que é um principio da OO. Portanto, não faz sentido que um motor de injeção possa criar um singleton. É como ter uma fabrica de singleton, simplesmente impossivel.

O ponto que abordei é a confusão de que um singleton possa ser criado via motor de DI. Não pode.

Agora entendi o seu ponto. Então discordamos mesmo (nestes pontos, pelo menos).

Eu consigo enxergar um singleton sendo criado fora da classe, desde que esse ser externo garanta a instância única. Claro, é uma visão diferente do GoF tradicional, e mais próxima do que se enxerga como singleton hoje no Spring e no próprio @Singleton

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

Paulo Silveira wrote:
Creio que todos estamos falando o mesmo: o pessoal costuma usar singleton erroneamente, por isso precisam ter cuidado, como o proprio Erich Gamma disse: I'm in favor of dropping Singleton. Its use is almost always a design smell.

Não creio que estamos. A frase que cistaste é um exemplo. O que é um smell ? o singleton ?
coitado. porque ele é , e registry ou factory ou proxy não são ? Porque se livrar ( drop) do singleton. Tipo todos os autores vão nunca mais escrever sobre ele, logo ele nunca mais será usado. Entendem ? isso não faz sentido.

O que ele deveria dizer era : precisamos explicar melhor, com mais exemplos para que as pessoas não achem que estão usando o padrão.

Um padrão tem um escopo onde pode ser usado. A maioria usa singleton no escopo errado. A implementação tecnica pode até ser perfeita, mas se o escopo é errado, é um smell. O escopo do uso, não o padrão e não o coitado do singleton.

Para os que não sabem porque eu estou falando o que estou falando releiam o topico todo ( e os n-trocentos do mesmo assunto).

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

Sergio Lopes wrote:

sergiotaborda wrote:Veja bem o conceito de singleton nasce da proibição explicita de injeção de dependencia que é um principio da OO. Portanto, não faz sentido que um motor de injeção possa criar um singleton. É como ter uma fabrica de singleton, simplesmente impossivel.

O ponto que abordei é a confusão de que um singleton possa ser criado via motor de DI. Não pode.

Agora entendi o seu ponto. Então discordamos mesmo (nestes pontos, pelo menos).

Eu consigo enxergar um singleton sendo criado fora da classe, desde que esse ser externo garanta a instância única. Claro, é uma visão diferente do GoF tradicional, e mais próxima do que se enxerga como singleton hoje no Spring e no próprio @Singleton

Dê um exemplo. Crie um mecanismo para criar o objeto de forma que ele seja um singleton sem que a classe crie o objeto. ( teste com runtime e desktop para ver se funciona. lembre-se que runtime é um recurso realmente único. )

This message was edited 1 time. Last update was at 27/10/2009 23:53:34

sergiotaborda wrote:
O que ele deveria dizer era : precisamos explicar melhor, com mais exemplos para que as pessoas não achem que estão usando o padrão.

Tem razao. Tirar do livro é exagero. Melhor seria ter esse tipo de discussão lá e mostrar exatamente o smell, mostrando que não é legal usar como variável global, difícil de testar se invocado o método estático em todos os lugares, etc, mas que da pra usar bem se tomar cuidado E tiver a real necessidade (que é dificil aparecer).

This message was edited 1 time. Last update was at 28/10/2009 00:03:28

sergiotaborda wrote:
Dê um exemplo. Crie um mecanismo para criar o objeto de forma que ele seja um singleton sem que a classe crie o objeto. ( teste com runtime e desktop para ver se funciona. lembre-se que runtime é um recurso realmente único. )

Crie uma interface publica que se chama Runtime e uma implementacao package-protected que se chama DefaultRuntime. Registre essa configuracao no seu container de DI, de que deve ter so um DefaultRuntime a ser injetado. O container usando um pouco de magica consegue dar new na classe paclage-protected. Pronto! Podia ate ter na System um getRuntime que devolvesse o DefaultRuntime unicamente instanciado. Codigo limpo, testavel (diferente de como é atualmente, impossivel de se testar unitariamente quem depende diretamente de Runtime sem magia negra), e é uma forma de implementar singleton. A unica forma de burlar isso seria por reflection+magia, e da pra fazer a mesma coisa com o singleton tradicional, entao estamos igualmente protegidos. Alias, essa tecnica é pra la de conhecida e muita gente usa de outras formas.

A falta de uma interface para Runtime, e qualquer outro singleton, é certamente um pequeno pecado.

Essa visao do Sergio Lopes, como ele disse, é diferente da tradicional, mas tem o mesmo efeito.

sergiotaborda wrote:

Paulo Silveira wrote:
Creio que todos estamos falando o mesmo: o pessoal costuma usar singleton erroneamente, por isso precisam ter cuidado, como o proprio Erich Gamma disse: I'm in favor of dropping Singleton. Its use is almost always a design smell.

Não creio que estamos. A frase que cistaste é um exemplo. O que é um smell ? o singleton ?
coitado. porque ele é , e registry ou factory ou proxy não são ? Porque se livrar ( drop) do singleton. Tipo todos os autores vão nunca mais escrever sobre ele, logo ele nunca mais será usado. Entendem ? isso não faz sentido.

O que ele deveria dizer era : precisamos explicar melhor, com mais exemplos para que as pessoas não achem que estão usando o padrão.

Um padrão tem um escopo onde pode ser usado. A maioria usa singleton no escopo errado. A implementação tecnica pode até ser perfeita, mas se o escopo é errado, é um smell. O escopo do uso, não o padrão e não o coitado do singleton.

Para os que não sabem porque eu estou falando o que estou falando releiam o topico todo ( e os n-trocentos do mesmo assunto).

Sinceramente nao foi o que entendi da frase do Gamma, ele disse que o USO do singleton é na maior parte um smell e nao propriamente o singleton.

Notícias, artigos e o maior fórum brasileiro sobre Java