Ho visto molte spiegazioni perché Singleton è malvagio. Ma non c'è davvero un caso del genere quando Singleton è l'unica soluzione bellissima?
vuoi ascoltare un mito comune?
"I singleton sono un modo per limitare il numero di istanze di una determinata classe a una."
Sì, giusto.
Se è così che la maggior parte delle persone ha usato i singleton, l'unica cosa che dovrei dire è "Bene, perché non creare UNO e fermarsi qui?"
Ma non è questo il problema. Il vero problema qui è che le persone usano i singleton per introdurre lo stato globale nei programmi orientati agli oggetti, o semplicemente per spingere in un altro (anti) modello.
Se vuoi avere una singola istanza di una certa classe, è perfettamente fine. Ma perché renderlo accessibile da qualsiasi parte del tuo codice? Si chiama opacità, amico mio, ed è quello che dovresti fare attenzione.
Invece di usare singleton, leggi ancora qualcosa sull'iniezione di dipendenza e sulla catena di costruzione (fabbriche, ecc.). Dipende dai servizi (oggetti) di cui hai bisogno. Non provare a trovarli da soli (dal punto di vista dell'oggetto) o accedervi globalmente.
Dipende da ciò che chiami Singleton.
Modifica > Il collegamento di Problematic nei commenti della domanda potrebbe aiutare a capire cosa intendo qui: Quando è appropriato Singleton?
Se la costruzione e la distruzione dell'istanza unica non devono essere esplicite, allora è EVIL.
In caso contrario, ci sono alcuni casi specifici in cui è chiaramente una buona soluzione. Il principale che sto usando è quando l'istanza univoca rappresenta lo stato di un "sistema" che è "globale", come una API hardware.
Detto questo, se sei in questo caso, puoi sostituire il tuo singleton con funzioni gratuite ... se la tua lingua lo consente. In caso contrario, suppongo che sia una scelta ragionevole.
Basta ricordare: l'accesso globale significa che se c'è un problema con il tuo oggetto singleton, potresti averlo propagato ovunque sia usato. Ecco perché se riesci a rimuovere l'accessibilità globale, sarebbe molto meglio.
In un modo più generale, quando inizi a pensare che un singleton potrebbe essere necessario, pensaci due o più volte. Può sempre essere sostituito. C'è solo un tradeof che potrebbe essere (o non) troppo costoso per te. Ora non significa che non devi usarlo affatto nella tua vita. Potrebbe valere la pena a volte. Ma è raro. Quindi, come regola generale, non usarlo. Le regole sono fatte per essere comprese e poi infrante quando capisci quando è una buona idea.
Sì.
Durante il tentativo di calzare un'app in un microcontroller minuscolo, molto memoria e / o con prestazioni limitate. Si può persino trasformare un singleton in una var / struct / array globale, che il compilatore può ottimizzare in un numero molto inferiore di byte di codice macchina.
Per oggetti di consumo di volume elevato, la bellezza spesso risparmia pochi centesimi o mm cubi. Generalità (portabilità, riusabilità, manutenibilità, ecc.) Ha dei costi. Non è necessario pagare se non si intende utilizzare i vantaggi associati a tali costi.
Non ho mai visto né sentito alcun caso che giustifichi la limitazione di un oggetto a una sola istanza.
Anche nell'hardware, non si può mai garantire ciò che può accadere nei prossimi anni: ad esempio, nel 1990 o nel 1995 si potrebbe dire che un driver grafico potrebbe ragionevolmente usarne uno. Ma poi, hai inventato SLi. Ops. Lo stesso è successo con le stampanti. Non puoi giustificare l'uso di un Singleton solo perché non ha senso - deve essere attivamente distruttivo del sistema. Tali istanze non esistono.
Leggi altre domande sui tag design-patterns singleton