Os singletons imutáveis ​​/ sem estado são ruins?

Ultimamente, tem havido algum tipo de revolução contra os singletons, mas há algo de errado com eles se são apátridas?

Eu conheço a conversa sobre uso excessivo e tudo ... isso se aplica a tudo, não apenas a singletons.

  > Are immutable/stateless singletons bad?

• Não, se eles não dependem de outros sistemas externos.
  • Exemplo: Uma Stringutility que escapa html dentro de uma string.
  • Motivo: em unittests, não há necessidade de substituí-lo por um simulador / simulador.
• Sim, se o seu singleton imutável / sem estado depende de outros sistemas / serviços externos e se você deseja fazer a unittesting (teste em isolamento)
  • Exemplo: um serviço que depende de um serviço de calculadora de imposto externo.
  • Motivo: para realizar unittests com este Serviço (isoladamente), você precisa simular / zombar dos Sistemas / Serviços externos.

Para mais detalhes, consulte the-onion-architecture

• Singleton-s pode tornar o teste de unidade (isoladamente) mais difícil / impossível e
• dependências / acoplamentos ocultos podem ser vistos como um problema, conforme explicado por @yBee

Não vejo outras razões pelas quais não usar Singletons.

Depende sempre do uso. Eu acho que a revolução vem do fato de que todo programador aprende esse padrão como o padrão orientado a objetos. A maioria esquece de pensar sobre onde faz sentido e onde não faz.
Obviamente, isso é válido para todos os padrões. Apenas usando padrões, você não cria um bom código ou um bom software.

Se você possui um singleton sem estado, por que não usar uma classe que oferece apenas métodos estáticos (ou uma classe estática)?

Aqui estão alguns posts sobre variáveis ​​globais e singletons em geral.

Eu não seria tão rigoroso quanto o autor, mas ele mostra que, na maioria dos casos em que você acha que precisa de um singleton, você realmente não precisa dele.

Não há nada que um singleton apátrida imutável possa fazer que uma classe estática não pode.

Simplesmente não há razão para adicionar o nível extra de complexidade que -> Instance () cria, enquanto a chamada simples para um método estático será mais clara, mais conservadora em termos de recursos e provavelmente mais rápida.

Não é que eles estejam errados. É que existe uma maneira melhor de fazer isso. Há cenários em que singletons normais ("com estado") são o caminho certo a seguir. O mal do singleton é que eles são frequentemente abusados, com os mesmos resultados ruins que as variáveis ​​globais, mas há casos específicos em que o uso de um singleton é simplesmente correto. Não existem casos para os apátridas.

O principal problema do singleton é que ele oculta dependências e acoplamentos, especialmente quando usado no cenário de preocupações transversais. Veja Singletons são mentirosos patológicos ou Por que Singletons são maus para leitura adicional.

Por outro lado, um estado menos singleton, se não for abusado, pode ser útil e melhorar o desempenho. Considere um exemplo:

interface Interface
{
    void Method();
}

class StatelessSingleton : Interface
{
    public static readonly StatelessSingleton Instance = new StatelessSingleton();
    private StatelessSingleton() { }

    public void Method() { }
}

class User
{
    public User(Interface i) { /* ... */ }
}

Aqui, o StatelessSingleton atua como implementação padrão da Interface e é colocado no construtor User. Não há acoplamentos codificados e dependências hiden. Não podemos usar uma classe estática devido à interface subjacente, mas não há razão para criar mais de uma instância de um padrão. É por isso que um singleton apátrida parece ser uma escolha apropriada.

No entanto, talvez devamos usar outro padrão para uma implementação padrão:

class Implementation : Interface
{
    private readonly Action _method;

    public Implementation()
    {
        _method = new Action(() => { /* default */ });
    }

    public Implementation(Action custom)
    {
        _method = custom;
    }

    public void Method()
    {
        _method();
    }
}

Ele atinge o desempenho em relação ao StatelessSingleton, mas constitui uma implementação genérica da Interface. Solução semelhante é usada pela interface IProgress .

Embora novamente, por que permitir criar mais de uma implementação do comportamento padrão? No entanto, podemos combinar os dois:

class Implementation : Interface
{
    public readonly Implementation Default = new Implementation();

    private readonly Action _method;

    private Implementation()
    {
        _method = new Action(() => { /* default */ });
    }

    public Implementation(Action custom)
    {
        _method = custom;
    }

    public void Method()
    {
        _method();
    }
}

Concluindo, acredito que há lugares (como os padrões descritos) em que Singletons são úteis. A principal definição de Singleton afirma que não é permitido criar mais de uma instância de uma classe. É como energia nuclear. Pode produzir uma energia ou uma bomba. Depende do humano.