I singleton immutabili / apolidi sono cattivi?

Ultimamente c'è stata una sorta di rivoluzione contro i single, ma c'è qualcosa di sbagliato in loro se sono apolidi?

Conosco il discorso sull'uso eccessivo e tutto il resto ... questo vale per tutto, non solo per i singoli.

  > Are immutable/stateless singletons bad?

• No se non dipendono da altri sistemi esterni.
  • Esempio: Stringutility che sfugge a HTML all'interno di una stringa.
  • Motivo: negli unittest non è necessario sostituirlo con un simulatore / simulatore.
• Sì, se il singleton immutabile / stateless dipende da altri sistemi / servizi esterni e se si desidera eseguire unittesting (test in isolamento)
  • Esempio: un servizio che dipende da un servizio esterno di calcolatrice fiscale.
  • Motivo: per effettuare unittest con questo servizio (in isolamento) è necessario simulare / deridere i sistemi / servizi esterni.

Per maggiori dettagli vedi the-onion-architecture

• Singleton-s può rendere i test unitari (isolati) più difficili / impossibili e
• dipendenze / accoppiamenti nascosti possono essere visti come un problema, come spiegato da @yBee

Non vedo altri motivi per cui non usare Singletons.

Dipende sempre dall'uso. Credo che la rivoluzione viene dal fatto, che ogni programmatore apprende questo schema come l' object oriented modello. La maggior parte dimentica di pensare a dove ha senso e dove no.
Questo, ovviamente, è vero per ogni modello. Solo usando i pattern non crei un buon codice o un buon software.

Se hai un singleton senza stato, perché non utilizzare una classe che offre solo metodi statici (o utilizzare una classe statica)?

Ecco alcuni post riguardanti variabili globali e singoli in generale.

Non sarei severo come l'autore, ma dimostra che per la maggior parte dei casi in cui pensi di aver bisogno di un singleton, non ne hai davvero bisogno.

Non c'è nulla che un singleton stateless immutabile possa fare che una classe statica non può fare.

Non c'è semplicemente alcun motivo per aggiungere il livello extra di complessità che -> Instance () crea, mentre la semplice chiamata a un metodo statico sarà più chiara, più conservativa in termini di risorse e probabilmente più veloce.

Non è che si sbagliano. È che esiste un modo migliore per farlo. Ci sono scenari in cui i singoli ("stateful") normali sono la strada giusta da percorrere. Il male con singleton è che vengono spesso abusati, con gli stessi cattivi risultati delle variabili globali, ma ci sono casi specifici in cui l'uso di un singleton è semplicemente corretto. Non ci sono casi simili per gli apolidi.

Il problema principale con singleton è che nasconde le dipendenze e l'accoppiamento soprattutto se utilizzato in scenari di problematiche trasversali. Vedi Singletons sono bugiardi patologici o Perché i singleton sono malvagi per ulteriori letture.

Dall'altro lato, uno stato meno singleton, se non abusato, può essere utile e migliorare le prestazioni. Considera un esempio:

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) { /* ... */ }
}

Qui StatelessSingleton funge da implementazione predefinita dell'interfaccia e viene inserito nel costruttore User. Non esistono accoppiamenti codificati e dipendenze hiden. Non siamo in grado di utilizzare una classe statica a causa dell'interfaccia sottostante ma non c'è motivo di creare più di un'istanza di un valore predefinito. Ecco perché un singleton apolide sembra essere una scelta appropriata.

Tuttavia, forse dovremmo usare un altro modello per un'implementazione predefinita:

class Implementation : Interface
{
    private readonly Action _method;

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

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

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

Colpisce le prestazioni rispetto a StatelessSingleton ma costituisce un'implementazione generica dell'interfaccia. Una soluzione simile viene utilizzata dall'interfaccia IProgress .

Anche in questo caso, perché consentire di creare più di un'implementazione del comportamento predefinito? Eppure possiamo combinare i due:

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();
    }
}

In conclusione, credo che ci siano posti (come impostazioni predefinite raffigurate) in cui i Singleton sono utili. La definizione principale di Singleton afferma che non consente di creare più di un'istanza di una classe. È come l'energia nucleare. Può produrre un'energia o una bomba. Dipende dall'essere umano.