Singleton

[Alberto]

Boa tarde galera!

 

Ouvi dizer que o padrão singleton está entrando em desuso.

Em um projeto que trabalhei, o contexto do EF, era armazenado em um singleton, onde em alguns momentos tínhamos problemas com informações desatualizadas, conseguimos resolver, mas essa afirmação acima me deixou curioso, o que vocês acham disso?

[Vinicius Quaiato]

Controverso o assunto:

http://blog.caelum.com.br/2006/08/08/singletons-e-static-perigo-a-vista/

Alguns mapearam o uso abusivo de Singletons como "singletonits". No livro do Joshua Kerievsky "Refatoring To Patterns" se não me engano o Kent Beck e o Ward Cunninghan escrevem um texto sobre por que Singletons são evil.

Não é que o pattern esteja em desuso, mas ele tem sido considerado um problema.

Em uma entrevista com o Erich Gamma (se não me engano) perguntaram o que ele colocaria ou removeria do livro do GoF, e ele disse que talvez removeria o Singleton do catálogo.

Abraços,

Vinicius Quaiato.

2010/10/13 Alberto <betim...@gmail.com>

Boa tarde galera!

 

Ouvi dizer que o padrão singleton está entrando em desuso.

Em um projeto que trabalhei, o contexto do EF, era armazenado em um singleton, onde em alguns momentos tínhamos problemas com informações desatualizadas, conseguimos resolver, mas essa afirmação acima me deixou curioso, o que vocês acham disso?

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Vinicius Quaiato]

Aqui temos alguns pontos interessantes também:

http://blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx

O primeiro ponto é bastante interessante!

2010/10/13 Vinicius Quaiato <vinicius...@gmail.com>

[Denis Ferrari]

Se está em desuso não sei. Eu ainda utilizo p/ algumas coisas.

Acredito que o maior problema não está no Pattern, mas sim em como os desenvolvedores utilizaram ele.

Abraços!

Denis Ferrari (@denisferrari) - "Faça pouco, faça sempre e faça direito"

www.heroisdati.com

2010/10/13 Vinicius Quaiato <vinicius...@gmail.com>

[Fábio Serratto (GMail)]

Como tudo na vida, o que é usado em excesso pode trazer problemas.

Uso Singleton para algumas coisas, mas sempre ponderado.

Já tivemos problemas com SingleTon principalmente quando mandávamos requisições Ajax em paralelo, tivemos que mudar a estratégia.

 

 

Fábio Serratto

Microsoft Certified Professional Developer: Web Developer

Microsoft Certified Technology Specialist: Microsoft .NET Framework - Web Applications

Microsoft Certified Technology Specialist: .NET Framework 4, Web Applications – Charter Member / Early Achiever

Microsoft Certified Application Developer: For Microsoft .Net

Microsoft Certified Professional

Microsoft Certified Trainer

Gerente de Negócios e Tecnologia

IT Extreme Consultoria e Desenvolvimento de Sistemas Ltda

www.itextreme.com.br

itx3.wordpress.com

twitter: @fabioserratto

 

"Aprender é a unica coisa de que a mente nunca se cansa, nunca tem medo e nunca se arrepende." (Leonardo da Vinci)

[Juan Lopes]

Um dos principais problemas do Singleton, na minha opinião, é o motivo pelo qual ele é usado. Geralmente o argumento das pessoas é que "parece tão feio ficar criando new Whatever() só para invocar um método dela". Normalmente as pessoas tornam o método static. Mas os que não gostam muito de static, acabam usando singleton, que além de não ser static, é dito ser um design pattern. Isso tudo só mascara o fato de que você não tem um objeto com estado e comportamento. Você tem simplesmente um monte de métodos agrupandos nisso que você chama de classe, mas que poderia, muito bem chamar de módulo.

Outro problema é que se você usa AppDomain singleton (o mais simples), você tem que lidar com diversos problemas de thread-safety, que começam na inicialização do objeto (afinal você não quer que ele seja inicializado duas vezes) e passa pelo acesso aos recursos compartilhados, como o Context do EF, no seu caso. Você pode até encher o seu código de locks, para garantir a safety das zonas críticas, mas o overhead que isso gera é geralmente maior do que deixar o objeto ser inicializado várias vezes.

Singleton é geralmente uma grande armadilha para péssimas práticas. É claro que há casos e casos, mas sempre desconfie.

2010/10/13 Denis Ferrari <denis....@gmail.com>

--
Kind regards,
Juan Lopes

[Vinicius Quaiato]

Não é só o exagero que causa problemas com singletons... no artigo que mandei:

http://blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx

Há exemplos práticos de design e arquitetura onde o singleton é problema, e não é apenas no paralelismo:

What ends up happening is that the dependencies in your design are hidden inside the code, and not visible by examining the interfaces of your classes and methods.

A class should not care whether or not it is a singleton. It should be concerned with its business responsibilities only. If you want to limit the ability to instantiate some class, create a factory or builder object that encapsulates creation, and in there, limit creation as you wish. 

Singletons promote tight coupling between classes
One of the underlying properties that makes code testable is that it is loosely coupled to its surroundings.

Persistent state is the enemy of unit testing.

 

São alguns dos fatores que fazem dos singletons "caras maus"!

E isso está ligado ao fato de SER singleton e não a forma como ele é usado.

Abraços,

Vinicius Quaiato.

2010/10/13 Denis Ferrari <denis....@gmail.com>

[Bruno D'Alessio]

"Bull's eye" Ferrari!

Bruno D'Alessio
Arquiteto de Software

[Juan Lopes]

É verdade, Vinicius. Esse é talvez o maior problema arquitetural do Singleton.

2010/10/13 Vinicius Quaiato <vinicius...@gmail.com>

--
Kind regards,
Juan Lopes

[Ramon Silva]

Queria saber quem falou isso... "Ouvi dizer que o padrão singleton está entrando em desuso."

Padrão é padrão. É neutro. O que pode estar sendo colocado é o mau uso do mesmo. 

Ramon Silva

www.start-it.com.br (minha empresa)
www.ramonsilva.com

  

Se pretende encaminhar este e-mail:
- Apague o meu endereço eletrônico e o meu nome.
- Encaminhe como cópia oculta (Cco ou Bcc) aos seus destinatários.

[Fábio Serratto (GMail)]

@Quaiato

Respondi antes de ler o post.

Deixa eu me explicar um pouco melhor....
Nos nossos projetos antigos utilizávamos fortemente o SingleTon, atualmente não estamos vendo tanta necessidade, mas se percebermos que vai nos ajudar em algum cenário, certamente utilizaremos.

O que eu acredito é que não adianta simplesmente fecharmos os olhos para o que já existia por estar caindo em desuso, existem coisas onde o bom e velho “arroz com feijão” resolvem bem o problema (ok, abriremos mão de algo mais moderno, práticas de design, testabilidade, acoplamento, etc e tal)

É só uma opinião pessoal

 

Fábio Serratto

Microsoft Certified Professional Developer: Web Developer

Microsoft Certified Technology Specialist: Microsoft .NET Framework - Web Applications

Microsoft Certified Technology Specialist: .NET Framework 4, Web Applications – Charter Member / Early Achiever

Microsoft Certified Application Developer: For Microsoft .Net

Microsoft Certified Professional

Microsoft Certified Trainer

Gerente de Negócios e Tecnologia

IT Extreme Consultoria e Desenvolvimento de Sistemas Ltda

www.itextreme.com.br

itx3.wordpress.com

twitter: @fabioserratto

 

"Aprender é a unica coisa de que a mente nunca se cansa, nunca tem medo e nunca se arrepende." (Leonardo da Vinci)

 

De: dotnetar...@googlegroups.com [mailto:dotnetar...@googlegroups.com] Em nome de Vinicius Quaiato
Enviada em: quarta-feira, 13 de outubro de 2010 13:22
Para: dotnetar...@googlegroups.com
Assunto: Re: [dotnetarchitects] Singleton

 

Não é só o exagero que causa problemas com singletons... no artigo que mandei:

[Vinicius Quaiato]

Ok... só estava demonstrando que as razões por ele ser considerado "evil" não é apenas o "uso desenfreado".

Cada um faz como quiser, mesmo sabendo dos problemas. :P

Abraços,

Vinicius Quaiato.

2010/10/13 Fábio Serratto (GMail) <serr...@gmail.com>

[VITOR CESAR]

Todos os padrões tem sua utilidade em um determinado contexto. Não dá para querer aplicá-los somente para dizer que seu projeto tem esse ou aquele padrão.

Penso que o mal uso e falta de conhecimento (e feeling), para realmente entender as necessidades com base no contexto é que são os problemas. 

 

Vitor Meriat Desenvolvedor C#  Brasília, DF Brasil		Casa: (61) 3021-9086 Mobile: (61) 8587-0613 Email: vitor...@gmail.com Email: vitor...@hotmail.com Twitter: @vitormeriat Perfil profissional Meu Blog

[Vinicius Quaiato]

Na vdd Vitor, esses problemas que eu mencionei INDEPENDEM  de contexto!

Esse acoplamento, quebra do SRP, problemas com testes, etc, inependem do seu contexto, eles são inerentes ao singleton: fato!

Aí vai de cada um arcar com este custo ou não.

Abraços,

Vinicius Quaiato.

2010/10/13 VITOR CESAR <vitor...@gmail.com>

[Denis Ferrari]

Pessoal,

Como vocês estão trabalhando com a configuração do NHibernate? Estão utilizando Singleton ou outro meio?

[Ricardo Borges]

"você deve evitar ao máximo a utilização de métodos estáticos e nem singletons. Como resolver essa nossa necessidade? Certamente com injeção de dependências. "

Um bom container de IoC pode ter diferentes ciclos de vida pra cada componente, inclusive singleton. 

NH:
Voce pode ter em seu projeto um container de IoC gerenciando a SessionFactory, e este ser um singleton na aplicação, o que é altamente recomendado pelo custo de construção de um objeto desses.

Ricardo Borges

[Denis Ferrari]

Obrigado pela resposta Ricardo.

Meu ponto é esse: Alguém não usa Singleton p/ gerenciamento da SessionFactory?

Abraços!

Denis Ferrari (@denisferrari) - "Faça pouco, faça sempre e faça direito"

www.heroisdati.com

2010/10/13 Ricardo Borges <ricard...@gmail.com>

[Juan Lopes]

Acho que todos usam. Mas lembrando que a SessionFactory é especialmente preparada para ser usada como Singleton, diferemente da Session.

Diretamente da SessionFactoryImpl:

This class must appear immutable to clients, even if it does all kinds of caching
and pooling under the covers.  It is crucial that the class is not only thread safe, 
but also highly concurrent.  Synchronization must be used extremely sparingly.

2010/10/13 Denis Ferrari <denis....@gmail.com>

--
Kind regards,
Juan Lopes

[Waldyr Felix - Gmail]

Oi pessoal,

Não acredito que Singleton seja tão "evil" assim, ao contrário do que disse Quaiato depende do contexto sim... Pois em OO os objetos tem que representar comportamentos do mundo real e se eu tenho que assegurar que o objeto só tem uma instancia, só posso usar Singleton ou deixa-lo estatico. No caso de representar arquivos de configuração, por exemplo, o singleton se encaixa muito bem.

Por outro lado, é altamente acoplado.

E não preciso usar lock para garantir que ele seja thread safe, basta fazer:

class Singleton {

 private static Singleton _instancia = new Singleton();
 public static Singleton Instancia {
    get { return _instancia; }
 }

}

[]s

--
  Waldyr Felix
  Engenheiro de Software
  MCP | MCTS
  (81) 8877 4459 | @waldyrfelix

[Vinicius Quaiato]

Como diz o texto que eu mandei, você pode delegar isso para uma factory e deixar a factory cuidar disso por exemplo.

OO não tem que representar comportamentos do mundo real, isso nem sempre é possível. OO é talvez a forma mais indicada para fazer isso, mas não é uma regra.

OO: abstração, encapsulamento, polimorfismo, herança, e mais algumas coisas.

E como eu disse, singleton é evil, mas vai de cada um arcar com os problemas que ele causa.

Abraços,

Vinicius Quaiato.

2010/10/13 Waldyr Felix - Gmail <waldy...@gmail.com>

[Denis Ferrari]

Bom, chegamos ao ponto.

Alguns medicamentos possuem contra-indicações, ainda assim usamos quando necessário e com orientação médica.

Como o @Juan disse lá no início, devemos olhar com desconfiança p/ o Singleton, mas não acho que precisamos acender as tochas e iniciar a caça às bruxas sempre que ouvirmos o nome do Pattern.

Abraços!

Denis Ferrari (@denisferrari) - "Faça pouco, faça sempre e faça direito"

www.heroisdati.com

2010/10/13 Juan Lopes <juanp...@gmail.com>

[Waldyr Felix - Gmail]

Concordo com vc @Denis, não é porque em alguns casos o Singleton é Evil que devemos acabar com ele. O Singleton é muito útil (pra quem sabe utilizá-lo dá forma correta).

Como o @Juan falou acho que todo mundo usa Singleton para gerenciamento da SessionFactory, mas alguém já teve problemas com isso?

Como vc faz @Quaiato?

[]s

--
  Waldyr Felix
  Engenheiro de Software
  MCP | MCTS
  (81) 8877 4459 | @waldyrfelix

[Vinicius Quaiato]

Se esse é o único cenário onde vocês usam Singleton, então nem deveríamos ter esta discussão :D

A questão é: Singleton TEM problemas de design, é inerente a ele. E como eu disse, se dá pra conviver com isso, ok.

Se vocês se usam Singleton com NH, então, go ahead. 

2010/10/13 Waldyr Felix - Gmail <waldy...@gmail.com>

Concordo com vc @Denis, não é porque em alguns casos o Singleton é Evil que devemos acabar com ele. O Singleton é muito útil (pra quem sabe utilizá-lo dá forma correta).

[Luciano Castilho]

A solução: http://desciclo.pedia.ws/wiki/Gambi_Design_Patterns#Doubleton

2010/10/13 Vinicius Quaiato <vinicius...@gmail.com>

--
Luciano Castilhos Fernandes

Módulo Solutions for GRC

[José Filipe Néis]

Só pra constar: nunca tive problemas com o NH em si, mas testar o código da nossa camada de configuração do NH foi um parto por causa do Singleton.

 

Acabei tendo que fazer arquivos de configuração da própria aplicação separados pra poder testar, se não fosse Singleton a volta teria sido menor.

 

Mas que Singleton vai atrapalhar a testabilidade, a não ser que use TypeMock, todo mundo já sabe. :-)

 

Abçs.

 

José Filipe

[Juan Lopes]

Waldyr, o problema de concorrência do singleton não para por ai. Se a sua classe tem um estado interno compartilhado como, digamos, um IDictionary, você precisa controlar o acesso a ele pelas diversas threads também. Ai não tem jeito, tem que fazer sincronização, provavelmente com lock.

Além disso, essa implementação de singleton que você mostrou é ruim pq ela é não-lazy, o que faz com que qualquer referência estática à sua classe faça com que o objeto seja inicializado. No caso de uma sessionfactory, isso pode significar vários segundos de espera ocupada. A implementação mais canônica de singleton no C# é algo como:

public class Singleton {

    class Inner { public static Singleton Instance = new Singleton(); }

    public static Singleton Instance { get { return Inner.Instance; } }

}

Essa é thread-safe e lazy initialized. Tem um artigo onde o cara compara as diversas implementações possíveis.

2010/10/13 Waldyr Felix - Gmail <waldy...@gmail.com>

Oi pessoal,

[Waldyr Felix - Gmail]

Humm, entendo @Juan a questão sobre concorrência, vai depender também das dependencias do objeto que vc está aplicando o Singleton.
Mas essa questão do lazy não entendi bem, pois de qualquer jeito um dia vou ter que inicializar essa classe, se vai ser antes ou depois a espera não seria a mesma?

[]s

--
  Waldyr Felix
  Engenheiro de Software
  MCP | MCTS
  (81) 8877 4459 | @waldyrfelix

[Roberta Arcoverde]

Se a ideia é manter um único estado, tem o padrão MonoState também. Alguém já usou/usa?

http://stackoverflow.com/questions/887317/monostate-vs-singleton

Roberta Lopes Arcoverde

[Jarbas Brito]

Aqui http://www.tectura.com.br/topics/padrao_singleton tem uma
discussão sobre isso também. Acho que deve agregar em alguma coisa.

[]s

Em 13/10/10, Roberta Arcoverde<roberta....@gmail.com> escreveu:

>>> artigo<http://codebalance.blogspot.com/2010/08/singleton-pattern-and-beyond.html>onde

>>>> Acho que todos usam. Mas lembrando que a SessionFactory é *especialmente
>>>>> preparada *para ser usada como Singleton, diferemente da Session.
>>>>>
>>>>> Diretamente da
>>>>> SessionFactoryImpl<https://nhibernate.svn.sourceforge.net/svnroot/nhibernate/trunk/nhibernate/src/NHibernate/Impl/SessionFactoryImpl.cs>

>>>>> :
>>>>>
>>>>> This class must appear immutable to clients, even if it does all kinds
>>>>> of caching
>>>>> and pooling under the covers. It is crucial that the class is not only
>>>>> thread safe,
>>>>> but also highly concurrent. Synchronization must be used extremely
>>>>> sparingly.
>>>>>
>>>>>
>>>>> 2010/10/13 Denis Ferrari <denis....@gmail.com>
>>>>>
>>>>>> Obrigado pela resposta Ricardo.
>>>>>>
>>>>>> Meu ponto é esse: Alguém não usa Singleton p/ gerenciamento da
>>>>>> SessionFactory?
>>>>>>
>>>>>> Abraços!
>>>>>>

>>>>>> Denis Ferrari (@denisferrari <http://twitter.com/denisferrari>) -

>>>>>> "Faça pouco, faça sempre e faça direito"
>>>>>> www.heroisdati.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2010/10/13 Ricardo Borges <ricard...@gmail.com>
>>>>>>
>>>>>> "você deve evitar ao máximo a utilização de métodos estáticos e nem
>>>>>>> singletons. Como resolver essa nossa necessidade? Certamente com
>>>>>>> injeção
>>>>>>> de dependências

>>>>>>> <http://www.martinfowler.com/articles/injection.html>.

>>>>>>> "
>>>>>>>
>>>>>>> Um bom container de IoC pode ter diferentes ciclos de vida pra cada
>>>>>>> componente, inclusive singleton.
>>>>>>>
>>>>>>> NH:
>>>>>>> Voce pode ter em seu projeto um container de IoC gerenciando a
>>>>>>> SessionFactory, e este ser um singleton na aplicação, o que é
>>>>>>> altamente
>>>>>>> recomendado pelo custo de construção de um objeto desses.
>>>>>>>
>>>>>>> Em 13 de outubro de 2010 14:04, Denis Ferrari <denis....@gmail.com
>>>>>>> > escreveu:
>>>>>>>
>>>>>>> Pessoal,
>>>>>>>>
>>>>>>>> Como vocês estão trabalhando com a configuração do NHibernate? Estão
>>>>>>>> utilizando Singleton ou outro meio?
>>>>>>>>
>>>>>>>> Abraços!
>>>>>>>>

>>>>>>>> Denis Ferrari (@denisferrari <http://twitter.com/denisferrari>) -

>>>>>>>>>>>> *Fábio Serratto*
>>>>>>>>>>>>
>>>>>>>>>>>> *Microsoft Certified Professional Developer: Web Developer*
>>>>>>>>>>>>
>>>>>>>>>>>> *Microsoft Certified Technology Specialist: Microsoft .NET
>>>>>>>>>>>> Framework - Web Applications*
>>>>>>>>>>>>
>>>>>>>>>>>> *Microsoft Certified Technology Specialist: .NET Framework 4,
>>>>>>>>>>>> Web Applications – Charter Member / Early Achiever*
>>>>>>>>>>>>
>>>>>>>>>>>> *Microsoft Certified Application Developer: For Microsoft .Net*
>>>>>>>>>>>>
>>>>>>>>>>>> *Microsoft Certified Professional*
>>>>>>>>>>>>
>>>>>>>>>>>> *Microsoft Certified Trainer*
>>>>>>>>>>>>
>>>>>>>>>>>> *Gerente de Negócios e Tecnologia*
>>>>>>>>>>>>
>>>>>>>>>>>> *IT Extreme Consultoria e Desenvolvimento de Sistemas Ltda*
>>>>>>>>>>>>
>>>>>>>>>>>> *www.itextreme.com.br* <http://www.itextreme.com.br/>* *
>>>>>>>>>>>>
>>>>>>>>>>>> *itx3.wordpress.com *
>>>>>>>>>>>>
>>>>>>>>>>>> *twitter: @fabioserratto*
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *"Aprender é a unica coisa de que a mente nunca se cansa, nunca
>>>>>>>>>>>> tem medo e nunca se arrepende." (Leonardo da Vinci)*
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *De:* dotnetar...@googlegroups.com [mailto:
>>>>>>>>>>>> dotnetar...@googlegroups.com] *Em nome de *Vinicius Quaiato
>>>>>>>>>>>> *Enviada em:* quarta-feira, 13 de outubro de 2010 13:22
>>>>>>>>>>>>
>>>>>>>>>>>> *Para:* dotnetar...@googlegroups.com
>>>>>>>>>>>> *Assunto:* Re: [dotnetarchitects] Singleton

>>>>>>>>>>>> Denis Ferrari (@denisferrari <http://twitter.com/denisferrari>)

>>>>>>>>>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

>>>>>>>>>>>> Para mais opções visite o grupo em
>>>>>>>>>>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net
>>>>>>>>>>>> Architects hospedado no Google Groups.
>>>>>>>>>>>> Para postar envie uma mensagem para
>>>>>>>>>>>> dotnetar...@googlegroups.com
>>>>>>>>>>>> Para sair do grupo envie uma mensagem para

>>>>>>>>>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

>>>>>>>>>>>> Para mais opções visite o grupo em
>>>>>>>>>>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net
>>>>>>>>>>>> Architects hospedado no Google Groups.
>>>>>>>>>>>> Para postar envie uma mensagem para
>>>>>>>>>>>> dotnetar...@googlegroups.com
>>>>>>>>>>>> Para sair do grupo envie uma mensagem para

>>>>>>>>>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

>>>>>>>>>>>> Para mais opções visite o grupo em
>>>>>>>>>>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net
>>>>>>>>>>>> Architects hospedado no Google Groups.
>>>>>>>>>>>> Para postar envie uma mensagem para
>>>>>>>>>>>> dotnetar...@googlegroups.com
>>>>>>>>>>>> Para sair do grupo envie uma mensagem para

>>>>>>>>>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

>>>>>>>>>>>> Para mais opções visite o grupo em
>>>>>>>>>>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>>>>>>>>>> --
>>>>>>>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net
>>>>>>>>>>>> Architects hospedado no Google Groups.
>>>>>>>>>>>> Para postar envie uma mensagem para
>>>>>>>>>>>> dotnetar...@googlegroups.com
>>>>>>>>>>>> Para sair do grupo envie uma mensagem para

>>>>>>>>>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

>>>>>>>>>>>> Para mais opções visite o grupo em
>>>>>>>>>>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net
>>>>>>>>>>> Architects hospedado no Google Groups.
>>>>>>>>>>> Para postar envie uma mensagem para
>>>>>>>>>>> dotnetar...@googlegroups.com
>>>>>>>>>>> Para sair do grupo envie uma mensagem para

>>>>>>>>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

>>>>>>>>>>> Para mais opções visite o grupo em
>>>>>>>>>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>

>>>>>>>>>> *Vitor*
>>>>>>>>>>
>>>>>>>>>> *Meriat*
>>>>>>>>>> Desenvolvedor C#
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <http://www.inforplus.inf.br/>Brasília, DF

>>>>>>>>>>
>>>>>>>>>> Brasil
>>>>>>>>>>
>>>>>>>>>> [image: Descrição: Descrição:
>>>>>>>>>> http://www.linkedin.com/img/signature/pic_plastic_slate_26x130.gif]
>>>>>>>>>>

>>>>>>>>>> *Casa:* (61) 3021-9086
>>>>>>>>>> *Mobile:* (61) 8587-0613
>>>>>>>>>>
>>>>>>>>>> *Email:* vitor...@gmail.com
>>>>>>>>>> *Email:* vitor...@hotmail.com
>>>>>>>>>>
>>>>>>>>>> *Twitter:* @vitormeriat <http://www.twitter.com/vitormeriat>
>>>>>>>>>> [image: Descrição: Descrição:
>>>>>>>>>> http://www.linkedin.com/img/signature/icon_in_blue_14x14.gif]*Perfil
>>>>>>>>>> profissional <http://br.linkedin.com/pub/vitor-meriat/1b/706/1a0>*
>>>>>>>>>> *Meu Blog <http://vitormeriat.wordpress.com/>*

>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net
>>>>>>>>>> Architects hospedado no Google Groups.
>>>>>>>>>> Para postar envie uma mensagem para
>>>>>>>>>> dotnetar...@googlegroups.com
>>>>>>>>>> Para sair do grupo envie uma mensagem para

>>>>>>>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

>>>>>>>>>> Para mais opções visite o grupo em
>>>>>>>>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net
>>>>>>>>> Architects
>>>>>>>>> hospedado no Google Groups.
>>>>>>>>> Para postar envie uma mensagem para
>>>>>>>>> dotnetar...@googlegroups.com
>>>>>>>>> Para sair do grupo envie uma mensagem para

>>>>>>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

>>>>>>>>> Para mais opções visite o grupo em
>>>>>>>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>>>>>>> hospedado no Google Groups.
>>>>>>>> Para postar envie uma mensagem para
>>>>>>>> dotnetar...@googlegroups.com
>>>>>>>> Para sair do grupo envie uma mensagem para

>>>>>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

>>>>>>>> Para mais opções visite o grupo em
>>>>>>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ricardo Borges
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>>>>>> hospedado no Google Groups.
>>>>>>> Para postar envie uma mensagem para dotnetar...@googlegroups.com
>>>>>>> Para sair do grupo envie uma mensagem para

>>>>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

>>>>>>> Para mais opções visite o grupo em
>>>>>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>>>>> hospedado no Google Groups.
>>>>>> Para postar envie uma mensagem para dotnetar...@googlegroups.com
>>>>>> Para sair do grupo envie uma mensagem para

>>>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

>>>>>> Para mais opções visite o grupo em
>>>>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Kind regards,

>>>>> *Juan Lopes*

>>>>>
>>>>> --
>>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>>>> hospedado no Google Groups.
>>>>> Para postar envie uma mensagem para dotnetar...@googlegroups.com
>>>>> Para sair do grupo envie uma mensagem para

>>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

>>>>> Para mais opções visite o grupo em
>>>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>>>
>>>>
>>>> --
>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>>> hospedado no Google Groups.
>>>> Para postar envie uma mensagem para dotnetar...@googlegroups.com
>>>> Para sair do grupo envie uma mensagem para

>>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

>>>> Para mais opções visite o grupo em
>>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>>
>>>
>>>
>>>
>>> --
>>> Kind regards,

>>> *Juan Lopes*

>>>
>>> --
>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>>> hospedado no Google Groups.
>>> Para postar envie uma mensagem para dotnetar...@googlegroups.com
>>> Para sair do grupo envie uma mensagem para

>>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

>>> Para mais opções visite o grupo em
>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>>
>>
>> --
>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
>> hospedado no Google Groups.
>> Para postar envie uma mensagem para dotnetar...@googlegroups.com
>> Para sair do grupo envie uma mensagem para

>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

>> Para mais opções visite o grupo em
>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>
>
>
>
> --
> Roberta Lopes Arcoverde
>

> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitec...@googlegroups.com
> Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br

--
*Jarbas B. M. Segundo*
Blog: http://www.jsegundo.com.br
Skype : jbmsegundo

[Nelson Rodrigo]

Olá pessoal

 

Eu concordo com o Denis. No livro “Utilizando UML e Padrões”, Craig Larman diz que a utilização de padrões em excesso é imaturo. É uma questão de discernimento, basta entender o cenário onde cabe a sua utilização.

 

 

Abraços,

 

Nelson R L Bassetto

Http://nelsonbassetto.com/

[Waldyr Felix - Gmail]

Os padrões emergem da necessidade de utilizá-los, há casos especificos para usar o Singleton, assim como qualquer outro padrão.
A grande sacada é saber quando e como usar este ou aquele padrão de maneira correta. Acredito que o Erich Gamma falou que tiraria o Singleton do livro do GoF pela confusão que ele gera, e não por ser inútil ou não ser considerado mais um padrão de projeto.

Aliás, falando nisso, quais os requisitos para uma solução genérica se tornar um padrão de projeto?

[]s

--
  Waldyr Felix
  Engenheiro de Software
  MCP | MCTS
  (81) 8877 4459 | @waldyrfelix

[Juan Lopes]

O mesmo requisito para uma idéia se tornar currículo: alguém publicar sobre.

E precisa ser alguém de respeito, senão acontece igual ao coitado do Karush que mesmo tendo publicado sobre as condições KKT mais de 10 anos antes de Kuhn e Tucker, frequentemente tem seu nome ignorado nas citações.

2010/10/13 Waldyr Felix - Gmail <waldy...@gmail.com>

Os padrões emergem da necessidade de utilizá-los, há casos especificos para usar o Singleton, assim como qualquer outro padrão.

[Vinicius Quaiato]

A questão do Singleton não é o uso em excesso! Há questões de design por detrás disso. Ele prejudica o design, essa é a questão.

Seja usando uma única vez, ou 10 vezes.

Singleton trás consigo esses problemas (mencionado nos posts anteriores), independente da quantidade de vezes que ele é usado.

2010/10/13 Nelson Rodrigo <nelso...@gmail.com>

[Giovanni Bassi]

Mas é comum que um singleton trabalhe com muito mais reads do que writes, e o tal do dicionário seja read-only. Nesse caso nao há problemas. O problema que você descreve nao é do singleton, mas de qualquer objeto.

 

2010/10/13 Juan Lopes <juanp...@gmail.com>

[Giovanni Bassi]

Eu acho ruim falar que Singletons são do mal. Há aplicação para eles que fazem sentido. Da mesma forma que uma variável global às vezes faz sentido, da mesma forma que uma classe estática às vezes faz sentido. Não vejo o padrão caindo em desuso, talvez ele esteja sendo menos usado porque está sendo usado melhor?

O maior problema é o pessoal com paternite, que acabou de aprender que o Singleton existe, e que começam a criar singletons em todo canto... Mas paternite cura sozinha depois de um ano e muita dor de cabeça.

2010/10/13 Vinicius Quaiato <vinicius...@gmail.com>

[Vinicius Quaiato]

Como eu disse, o Singleton tem problemas de design inerentes a ele. Se são problemas suportáveis, ok. Mas eles existem e não se pode negar.

2010/10/14 Giovanni Bassi <gig...@giggio.net>

[Giovanni Bassi]

Não são problemas, são features. É como o padrão é. Se ele se encaixou perfeitamente na solução de um problema, porque considerar o design um problema? Se não encaixar, busquemos outra coisa.

2010/10/14 Vinicius Quaiato <vinicius...@gmail.com>

[Giovanni Bassi]

Não são problemas, são features. É como o padrão é. Se ele se encaixou perfeitamente na solução de um problema, porque considerar o design um problema? Se não encaixar, busquemos outra coisa.

2010/10/14 Vinicius Quaiato <vinicius...@gmail.com>

Como eu disse, o Singleton tem problemas de design inerentes a ele. Se são problemas suportáveis, ok. Mas eles existem e não se pode negar.

[Vinicius Quaiato]

Não acho que alto acoplamento e quebra de SRP seja de fato uma feature... e se for, é uma feature problemática.

Há casos em que isso talvez não signifique nada, mas não vejo como features. Podem sim ser características do padrão, como eu disse, faz parte dele. Mas são problemas que precisam ser considerados. E dependento dos casos, problemas sérios.

É como falamos em uma outra thread, sobre testar um método que usa um DateTime.Now internamente.

Singletons provocam isso, mas se para o cenário isso é aceitável, ok.

2010/10/14 Giovanni Bassi <gig...@gmail.com>

[Ricardo Borges]

Não estou conseguindo relacionar o pattern singleton com o problema de alto de acoplamento, tendo em mente que a maioria dos containers de IoC permite a configuração do ciclo de vida dos componentes, e que o fato de ser um singleton ou não, não impede de ser resolvido por uma interface sem referencias a nenhuma classe concreta.

Ricardo Borges

[Juan Lopes]

Acho que o Singleton ao qual o Vinicius se refere é este.

O que os containers de DI fazem, geralmente é garantir a unicidade de um objeto dentro de um certo contexto (o Singleton, do ponto de vista matemático). Já o Singleton pattern é estritamente a implementação da classe que mostrei acima.

2010/10/14 Ricardo Borges <ricard...@gmail.com>

--
Kind regards,
Juan Lopes

[Ricardo Borges]

*Singleton lifetime/lifecycle... sei lá... Essa opção não seria ideal pra evitar os problemas do pattern?

Algumas aplicações realmente precisam de uma instância única pra determinado componente. Ex: NH SessionFactory

[Vinicius Quaiato]

Ricardo, veja, se você por saber que sua session factory é um singleton, chamar ela diretamente de dentro de uma classe que a use, você criou essa dependência, ao invés de permitir que ela seja injetada nessa classe por um container.

O problema de acoplamento do singleton é esse:

public class AlgumaClasse

{

    public void FazAlgumaCoisa()

    {

          //operações

          if(DateTime.Now){/*coisas*/}

    }

}

Se no lugar do DateTime.Now você tiver uma chamada pra um singleton, sua classe está acoplada ao singleton, e não tem como injetar ele ali. Esse é um dos problemas com singleton.

Como eu disse e o artigo que mandei lá nos primeiros emails: "uma classe NÃO deveria saber que ela é um singleton, que tem que cuidar disso é uma factory ou um container". Aí sim, você tem uma classe e quem cuida dela ser singleton ou não é outra pessoa e não ela mesma. Assim você consegue trabalhar ela como dependência de outras classes e usar um container numa boa, acabando com o acoplamento.

2010/10/14 Ricardo Borges <ricard...@gmail.com>

[Ricardo Borges]

Exato, materializando o exemplo, um container pode gerenciar esse lifecycle:

http://www.castleproject.org/container/facilities/trunk/nhibernate/index.html

[Vinicius Quaiato]

Desde que a dependência seja explícita, e o singleton não seja implementado, mas gerenciado.

2010/10/14 Ricardo Borges <ricard...@gmail.com>

[Sidney Lima Filho]

Vinicius, seguindo o seu exemplo do DateTime.Now, me fala sua visão sobre: - Porque injetamos dependencia para o SessionFactory, mas não injetamos para o DateTime se ambos são SingleTon? - Porque injetamos dependencia dos objetos externos, mas não injetamos para os objetos do .NET Framework? Posso estar com uma visão limitada, mas vejo que existe uma necessidade natural da existencia do SingleTon. O SingleTon não se torna bom ou ruim, devido a utilização ou não de um DI. Existem formas de usar o SingleTon, sem DI, que não acoplam o código e etc. Logo porque ele seria ruim? Atenciosamente Sidney Lima Filho  Vivina Softhouse (0xx21) 7867-2321 55*10*68934 http://www.vivina.com.br   |    http://twitter.com/vivina

2010/10/14 Vinicius Quaiato <vinicius...@gmail.com>

[Juan Lopes]

Usar DateTime.Now acopla e dificulta o teste. Isso é fato. Assim como File.ReadAllText ou HttpContext.Current. Fato é que DateTime.Now não é singleton, mas anyway...

Respondendo, então. Injetam DateTime, sim! Injetam objetos do .NET Framework, sim! A própria Microsoft criou a System.Web.Abstractions, reconhecendo que coisas que HttpContext.Current são uma porcaria.

Essas formas de Singleton sem DI acoplam, sim, o código. E creio que não existe uma necessidade natural para elas.

2010/10/15 Sidney Lima Filho <sidney...@vivina.com.br>

[Thiago Alves]

Pois é... acho que em geral é uma boa prática programar pensando em múltiplas referências de objeto, usando DI, e poder ter a liberdade de associar estas referências a uma única instância, através do Singleton,  Ou seja, os objetos que consomem o Singleton "acham" que na verdade se trata de múltiplas instâncias. Isso diminui o acoplamento, aumenta a testabilidade e a flexibilidade da arquitetura.

2010/10/15 Juan Lopes <juanp...@gmail.com>

[Vinicius Quaiato]

Sidney eu não disse que o DateTime.Now está certo, pelo contrário, disse que ele é uma dependência que não está clara e não pode ser injetada, exatamente igual acontece no uso de singletons.

O padrão singleton tem design issues que eu mencionei nos primeiros posts, leia lá. 

Ao invés de usar o padrão singleton uma alternativa bem simples é usar um lifecycle singleton, implementado por uma factory ou por um container, assim as dependências ficam claras e injetáveis, sem design issues.

Dependendo da dependência dos objetos do .NET eu injeto sim, como não? Stream, etc etc. Se isso impactar no teste eu inverto o controle e passo a usar DI.

Em resumo: o padrão Singleton tem design issues, o lifecycle singleton permitem contorná-los. Basta entender a diferença entre os dois.

Abraços,

Vinicius Quaiato.

2010/10/15 Sidney Lima Filho <sidney...@vivina.com.br>

[Thiago Alves]

Ou seja, em vez de:

public class MyClientClass {

     private readonly MySingletonClass obj;

     public DAO() {

          this.obj = MySingletonClass.GetInstance(); // ou algo do tipo

     }

}

prefiro

public class MyClientClass {

     private readonly MySingletonClass obj;

     public DAO(MySingletonClass obj) {

          this.obj = obj;

     }

}

// configuração do container de DI

container.RegisterInstance<MySingletonClass>(MySingletonClass.GetInstance()); 

2010/10/15 Thiago Alves <thiag...@gmail.com>

[Vinicius Quaiato]

Melhor ainda: você diz pro seu container que uma determinada classe deve ser singleton, e você NÃO implementa nenhuma classe como singleton.

Ou seja, a responsabilidade de garantir uma única instância não está no singleton, está no container, você mantem sua classe "singleton" apenas com a responsabilidade da regra de negócio dela, e o container injeta isso de forma transparente.

I think it's better.

Abraços,

Vinicius Quaiato.

2010/10/15 Thiago Alves <thiag...@gmail.com>

[Thiago Alves]

Sim. Na verdade foi isso o que eu quis dizer originalmente mas acabei me enrolando no exemplo. Obrigado pela correção :)

2010/10/15 Vinicius Quaiato <vinicius...@gmail.com>