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

fredferrao wrote:

sergiotaborda wrote:O que é um smell ? o singleton ?
coitado. porque ele é , e registry ou factory ou proxy não são ?

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.

verdade, bom ponto. ja estava respondido.

This message was edited 2 times. Last update was at 28/10/2009 00:29:54

sergiotaborda wrote:Crie um mecanismo para criar o objeto de forma que ele seja um singleton sem que a classe crie o objeto

Taborda, acredito mais na resolução das motivações descritas nos catalogos do que nos padrões conforme criados em sua essência. Ainda insisto na implicancia com anotações como @Singleton. De fato é uma factory que o cria, mas se o container que a contém é responsável pela ciclo de vida do objeto e garante que ele é único, mesmo isso não estando no objeto, ele resolve a questão Singleton de "possuir apenas uma instancia na aplicação". A associação deste comportamento com o nome "Singleton" é muito forte, logo não vejo mal em criar uma anotação com o mesmo nome para propósito similar.

O mesmo vale para mecanismos de cluster de alguns appservers onde para garantir um "comportamento Singleton" em mais de uma maquina virtual , é habilitado um servico ativo/passivo onde o controle da instancia fica a cargo do container e não do objeto... tendo o exato comportamento Singleton do padrão (vide HA-Singleton).

Java Ninja Membro desde: 04/04/2007 19:21:36 Mensagens: 268 Offline

sergiotaborda wrote:

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

Sim, tão genial que não preciso me preocupar com isso e mais, se me preocupar, é com apenas 1.

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

Irinia ou não, simplicidade é genialidade e complexidade não é talento. Quero me preocupar com o negócio que o cliente deseja fazer funcionar e que me dê suporte para testar e retestar se eu alterar. Pouco importa qual pattern usou o sistema para o cliente e sinceramente, o que mais me importa é criar um software funcional, no prazo e ao mesmo tempo não seja um emaranhado de classes com nomenclaturas e padrões que mudam todas as horas.

sergiotaborda wrote:
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".

Novamente, 1 padrão. Não mais que isso. De quantos padrões se faz um aplicativo em java? Será que levaria quanto tempo para entender tal padrão? Será que preciso saber ele para escrever bom software no Rails? A resposta é NÃO!
Agora, um framework X + Y + Z ainda preciso saber pattern A+B+C, logo, aqui estou, NA MESMA. Ai vem outro e quer adicionar mais um padrão XYZ porque é melhor que usar ABC e pronto, LÁ VAMOS NóS no barco da complexidade.
Enquanto isso, em uma linguagem bem elaborada necessita de 1 pattern, não me faça rir.

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

Só ler livros não lhe faz um bom programador. Só praticar também não. Precisamos dos dois e ao mesmo tempo, o $$$ é necessário para conseguirmos mais livros.

sergiotaborda wrote:
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 ?

Não culpo a Sun e nem o Java. Pra ser sincero, nem sei porque tamanha complexidade é dão idolatrada e dão adotada nas empresas e porque, uma linguagem tão mais inteligente, mais fácil de escrever não teve seu lugar ao sol como o Java. Seria porque a Sun já foi bem grande? Talvez, olha o .Net, Microsoft por trás e pum, as empresas grandes adotam.

JavaTeenager Membro desde: 11/04/2005 12:51:05 Mensagens: 199 Offline

Sergio Lopes wrote:
......

Compare qual código deixa as duas classes mais desacopladas:

class PrecisoDeUmCaraSingleton { PrecisoDeUmCaraSingleton() { SouUmSingleton s = SouUmSingleton.getInstance(); } }

ou:

class PrecisoDeUmCaraQueNãoSeiSeÉSingleton { PrecisoDeUmCaraQueNãoSeiSeÉSingleton(NãoSeiSeÉSingletonENãoMeInteressa n) { // injecao de dependencia } }

No fim, singleton hoje deixou de ser Design Pattern de código e passou a ser configuração de escopo em containers IoC.

Oi Sergio,

não estou aqui dizendo se Singleton é bom ou ruim, mas, na minha opinião, seu código mostra um problema de dependência, e não de singleton. Por exemplo:

acima temos um acoplamento maior independente do singleton em si.

Ola Salgado!

Voce tem razao, e o Sergio Lopes quis apontar realmente o problema da dependencia: usar o singleton sem cuidado gera um acoplamento fortissimo, dificultando tudo inclusive testes unitarios. Assim como o Erich Gamma tambem disse, o problema é nao usar o padrao direito, e nao o padrão em si.

JavaTeenager Membro desde: 11/04/2005 12:51:05 Mensagens: 199 Offline

Paulo Silveira wrote:Ola Salgado!

Voce tem razao, e o Sergio Lopes quis apontar realmente o problema da dependencia: usar o singleton sem cuidado gera um acoplamento fortissimo, dificultando tudo inclusive testes unitarios. Assim como o Erich Gamma tambem disse, o problema é nao usar o padrao direito, e nao o padrão em si.

Paulo,

levando em conta as duas implementacoes 'erradas' abaixo:

o teste das 2 implementações fica difícil independente do singleton (como dito antes).

Quando não é singleton nada pode ser feito, quando é singleton, alguns gatos são possíveis:

Código mau feito é difícil de testar. Mas nesse caso específico, com singleton ainda é possível tentar fazer um gato.

Acredito que este artigo da InfoQ vem bem a calhar nesta discussão:

http://www.infoq.com/br/news/2009/10/dissecting-technical-debt

Como o Luca disse, sobre se preocupar com o problema primeiro e refatorar depois, tenho a dizer que isso só é válido se vc sabe dos juros que serão cobrados sobre isso.

A refatoração deve acontecer a todo momento [Martin Fowler], vc se preocupa inicialmente somente com o problema e aí vai refatorando, refatorando até ter um código "decente".

A aplicação de Patterns, além de mostrar soluções para problemas conhecidos, também favorece uma comunicação universal entre os desenvolvedores.

Como foi dito aqui, só use Patterns se vc realmente tem um problema que precise dele. Mta gente utiliza Patterns apenas por usar e sem saber o pq ele realmente existe.

Mas se tratando do problema da curva de conhecimento necessária, creio que É necessária. Se podemos evitar defeitos futuros, pq não saber como evitar?

Palavras de Mary Poppendieck:

"O maior defeito que temos agora [em desenvolvimento de software] é tolerar defeitos"

Abraços.

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

fredferrao wrote: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.

Pois é, foi isso que ele disse. E é exactamente esse o problema. Quando vc usa o singleton corretamente isso não é errado. Exemplos sao Runtime e Desktop do JSE. quando cria um objeto que não é um singleton ,mas vc implementa o codigo igual ao que usaria num singleton isso sim é errado. Mas veja, não é o padrão que está errado, é o entendimento do programador que achou que singleton serve para dar acesso global.

Ainda hoje estava repassando um artigo da javamagazine sobre jruby e o autor escrevia algo como (parafrase) :" podemos tornar o objeto jrubyqualquercoisa (não lembro de cabeça o nome e não tenho a revista aqui) um singleton para podermos ter acesso global"

Este é o exemplo típico do mau uso de singleton. Quer acesso global ? use Registry. Quer uma única instância ? use singleton.
Singleton não é para dar acesso global (senão o nome do padrão seria Globalizator

)

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

Um comentário geral.

O exemplo do Paulo de como implementar singleton não é válido. Acho que vcs sempre se esquecem do essencial e continuam confundindo singleton e shared. Veja bem, o propósito do singleton não é manter um objeto unico na memória. Isso o shared tb faz. O objetivo é proibir que mais do que um objeto seja criado sob qualquer condição. Se vc usa interfaces as possibilidades do numero de objetos é ilimitada. A unica forma de proibir a instanciação é ter uma classe final e com construtor privado. Se o construtor é privado apenas a classe ela mesma ,pode criar a unica instância que existirá. Leiam o Effective Java para mais detalhes.

Os motores de injeção são feitos de vários padrões. claro. A questão é que em algum ponto os objetos que eles injetam têm que ser criados. Durante a fase de criação ela só pode ser feita por um padrão criacional.

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.

Um objeto shared pode ser descartado, e um outro da mesma classe colocado no seu lugar. Um objeto singleton não pode ser descartado. Por tudo que vc faça sempre apenas será possivel criar apenas uma instancia.

Como já disse, não é possivel usar um motor de injeção para criar um singleton, porque o singleton é feito proibindo toda e qualquer inversão de controle relativa à criação do objeto da classe. O mecanismo de controle da criação tem que ser tal que em qualquer uso da classe apenas uma instância seja criada. Então, tem que funcionar assim, mesmo na ausência de um motor de DI.
Lembrem-se que o singleton é um padrão criacional.

@Singleton é uma aberração por estes motivos. Vc cria um session bean. Vc cria uma interface e uma implementação. A implementação não tem qualquer mecanismo que evite que mais do que um objeto seja criado. aliás, a especificação manda que tenha um construtor publico sem argumentos. Um construtor publico é a antitese do singleton.
O que @Singleton significa é : crie uma instancia desta classe e mantenha-a criada. Sempre que alguem pedir por uma instancia desta classe retorne esta que vc mantem. É uma forma de cache que só permite guardar um objeto de cada classe. (Isto é o padrão Shared Object). O @Singleton não evitará que mais um objeto seja criado. É simples pq. Se o contrutor é publico e sem argumentos nada me impede de requisitar um novo objeto dando um new.

Mais uma vez : singleton não significa "mantenha uma unica instancia" significa "não permita que mais do que uma seja criada". Este não permita é uma condição forte. Não permita sob nenhuma condição. E é por isso que ele é um padrão criacional.

Algumas pessoas falam que reflection estraga o padrão singleton. Tente usar reflection para criar uma instancia de Runtime ou Desktop.

Algumas pessoa falam que serializable estraga o padrão singleton. Ora, se um objeto é serializavel e pode ser enviado a outra máquina ou para o disco, é obvio que este objeto está sendo partilhado por estes diversos lugares. Ele é , na realidade um shared object.Chamar-lhe singleton nao o torna singleton. Experimente usar esses truques para instanciar Runtime ou desktop.

Singletons verdadeiros são invioláveis. Caso contrário não são singletons, mesmo que sejam chamados de singletons em alguma documentação.
A taxionomia dos padrões é bem clara e acontece ao nivel abstrato e das responsabilidades , nunca da implementação. Julgar se o objeto X é singleton ou não depende de várias coisas. Se alguma delas falha, o objeto não é um singleton.

Mecanismos de DI não podem tornar uma classe singleton. Não é possivel. Simplesmente não é. Eles tornam shared facilmente,mas não singleton.

O adjetivo Singleton usado em @Singleton e na documentação de motores de DI é um erro historico. É uma má interpretação do padrão singleton (na realidade é um truque de publicidade para fazer o motor melhor do que é prometendo que ele gerencia singletons. O que é mentira) . mas o fato de ser usado assim, chamado assim , não significa que o padrão singleton está sendo usado. Não está. O @Singleton é a perpetuação do smell de mal-usar o padrão singleton. Ele é tão aberrante quanto usar singleton para fazer o acesso global.

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?

Muito interessante o nível da discução.

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.

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.

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

peczenyj wrote: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?

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.

This message was edited 3 times. Last update was at 28/10/2009 10:22:49

sergiotaborda wrote:
Algumas pessoas falam que reflection estraga o padrão singleton. Tente usar reflection para criar uma instancia de Runtime ou Desktop.

Vou te ensinar um truque legal, creio entao que voce nao conheca:

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?

JavaBaby Membro desde: 26/03/2006 20:30:54 Mensagens: 97 Offline

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.

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

Paulo Silveira wrote:

sergiotaborda wrote:
Algumas pessoas falam que reflection estraga o padrão singleton. Tente usar reflection para criar uma instancia de Runtime ou Desktop.

Vou te ensinar um truque legal (...)

javadoc de sun.reflect.ReflectionFactory wrote:
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 .

Isso não é reflection:
1) Não está no pacote java.lang nem java.lang.reflect.
2) Não é portável. Só funciona na jvm da sun.
3) Vc já deveria saber a esta hora que não se devem usar classes do pacote sun.*
4) 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.

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