Sobre Factory

Programação Arquitetura
#1

Eu já ví vários exemplos de Factory, codificados:

MyFactory factory = new MyFactory(); Product p = factory.getProduct( );

E também:

MyFactory factory = MyFactory.getFactory(); Product p = factory.getProduct( );

E também:

Dos três exemplos, qual o mais adequado/correto?

Abraços

#2

O primeiro não usa a ideia de AbstractFactory e os outros dois usam singleton, que não acho uma boa idéia usar.

#3

o que vc sugere?

#4

Use algum container de injecao de dependencias, como PicoContainer, Spring, HiveMind, Avalon, etc etc etc, ao inves de criar Factories. Eh mais facil, simples, rapido e testavel. E nao provoca caries, de quebra :wink:

#5

Factories tem seus usos cv, o ruim aqui é o singleton. Usar algum mecanismo de IoC, seja por injeção ou busca de dependencias.

#6

Fala Louds !!!

Por que singleton não é uma boa para uma factory ???

Não é legal eu centralizar a criação dos meus objetos numa instância só ???

Vai que amanhã eu quero fazer um pool de instâncias, por exemplo ???

Qual o mal do singleton ???

Um abraço,

Sergio

#7

Singleton é para garantir a existencia de somente uma instancia da classe. Achar 1 use-case onde isso é um requisito é realmente raro, nos outros casos vc está usando o anti-pattern “gambiarra lookup”.

Uma factory é interessante não ser um singleton por vários motivos, vou dar um exemplo concreto para não parecer pura retórica.
Se a sua factory não for um singleton, refatorar seu código para instroduzir o pattern de abstract factory fica muito mais facil, do trivial para o infernal eu diria.

#8

Olá

Vou me meter neste papo:

  1. Singletons não escalam bem porque são dificeis de controlar quando se põe a aplicação em cluster;

  2. Com EJBs é dificil usar Singletons por vários motivos como as restrições das variáveis estáticas read/write e também por race conditions. Singletons não podem ser synchronized com EJBs e todos os EJBs no mesmo container vão compartilhar a mesma instância. Não há como controlar o acesso concorrente. A alternativa de usar RMI para criar Singletons como objetos remotos é complicado e como não são gerenciados pelo EJB container, podem virar um single point of failure.

  3. Singletons são inimigos mortais da testabilidade pois é muito dificil substituir um Singleton por um test stub

  4. Singletons não deixam facilidades do tipo hot redeploy funcionar corretamente por permanecem com objetos no cache bloqueando mudanças na configuração.

  5. Em tempos de uso de containers IoC, Singletons de qualquer tipo ficam completamente por fora das vantagens de uso de IoC

  6. Além de se poder usar cluster há diversas outras vantagens de se evitar Singletons usando um um objeto de contexto de aplicação tipo ServletContext ou registry :
    :arrow: Flexibilidade de projeto programando por interfaces e sem depender muito de variáveis estáticas;
    :arrow: Os “Singletons” podem ser JavaBeans configurados pelas propriedades dos beans;
    :arrow: Podemos recarregar os valores do “Singleton” inclusive com JMX
    :arrow: Podemos ter um ponto único de configuração ao invés de um para cada Singleton.

Resumindo: não é que Singletons nunca devam ser usados como bem disse o louds. O problema é que a partir do momento em que usamos nossa aplicação perde escalabilidade e versatilidade.

Aguardo outras opiniões que me complementem.

[]s
Luca

#9

Fantastico seu post, Luca. Resumiu perfeitamente tudo que eu tenho tentado dizer faz um bom tempo aqui no GUJ sobre singletons :smiley:

Update: claro, sem a eloquencia toda. “Faiz parte!” :stuck_out_tongue:

#10

Olá

CV, veja o que acabei de dizer neste instante para o rafael:[list]“realmente o louds e o cv há tempos atrás me chamaram a atenção para os riscos de se abusar de singletons.
Hoje vejo que eles tinham razão”[/list]
[]s
Luca

#11