Iniezione delle dipendenze e pattern di progettazione singleton

Come si identifica quando utilizzare l'inserimento delle dipendenze o il pattern singleton. Ho letto in molti siti Web in cui si dice "Use Dependency injection over singleton pattern". Ma non sono sicuro di essere totalmente d'accordo con loro. Per i miei progetti su piccola o media scala, vedo sicuramente l'uso del pattern singleton semplice.

Ad esempio Logger. Potrei usare Logger.GetInstance().Log(...) Ma, invece di questo, perché devo iniettare ogni classe che creo, con l'istanza del logger ?.

Se vuoi verificare cosa viene registrato in un test, hai bisogno di inserimento delle dipendenze. Inoltre, un logger è raramente un singleton: generalmente hai un logger per ciascuna classe.

Guarda questa presentazione sul design orientato agli oggetti per la testabilità e vedrai perché i singleton sono cattivi.

Il problema con i singleton è che rappresentano uno stato globale difficile da prevedere, soprattutto nei test.

Tieni presente che un oggetto può essere de facto singleton ma può comunque essere ottenuto tramite l'iniezione di dipendenze, piuttosto che tramite Singleton.getInstance().

Sto solo elencando alcuni punti importanti fatti da Misko Hevery nella sua presentazione. Dopo averlo visto, acquisirai una prospettiva completa sul motivo per cui è meglio che un oggetto definisca quali sono le sue dipendenze, ma non definisci un modo per crearle .

I single sono come il comunismo: entrambi suonano benissimo sulla carta, ma esplodono di problemi nella pratica.

Il pattern singleton pone un'enfasi sproporzionata sulla facilità di accesso agli oggetti. Evita completamente il contesto richiedendo che ogni consumatore utilizzi un oggetto con ambito AppDomain, senza lasciare opzioni per diverse implementazioni. Incorpora la conoscenza dell'infrastruttura nelle tue classi (la chiamata a GetInstance()) aggiungendo esattamente zero potenza espressiva. In realtà diminuisce il tuo potere espressivo, perché non puoi cambiare l'implementazione usata da una classe senza cambiarla per tutte . Semplicemente non puoi aggiungere funzionalità una tantum.

Inoltre, quando la classe Foodipende Logger.GetInstance(), Foonasconde efficacemente le sue dipendenze ai consumatori. Ciò significa che non puoi comprenderlo completamente Fooo usarlo con fiducia a meno che tu non legga la sua fonte e scopri il fatto che dipende Logger. Se non si dispone del codice sorgente, ciò limita la capacità di comprendere e utilizzare efficacemente il codice da cui si dipende.

Il modello singleton, implementato con proprietà / metodi statici, è poco più di un trucco per implementare un'infrastruttura. Ti limita in una miriade di modi, senza offrire alcun vantaggio distinguibile rispetto alle alternative. Puoi usarlo come preferisci, ma poiché ci sono alternative valide che promuovono un design migliore, non dovrebbe mai essere una pratica consigliata.

Altri hanno spiegato molto bene il problema con i singleton in generale. Vorrei solo aggiungere una nota sul caso specifico di Logger. Sono d'accordo con te sul fatto che di solito non è un problema accedere a un logger (o al root logger, per la precisione) come singleton, tramite uno statico getInstance()o un getRootLogger()metodo. (a meno che tu non voglia vedere cosa viene registrato dalla classe che stai testando - ma nella mia esperienza difficilmente riesco a ricordare casi in cui ciò fosse necessario. D'altra parte, per altri questa potrebbe essere una preoccupazione più urgente).

IMO di solito un logger singleton non è un problema, poiché non contiene alcuno stato rilevante per la classe che stai testando. Cioè, lo stato del logger (e le sue possibili modifiche) non hanno alcun effetto sullo stato della classe testata. Quindi non rende i tuoi test unitari più difficili.

L'alternativa sarebbe iniettare il logger tramite il costruttore, in (quasi) ogni singola classe nella tua app. Per la coerenza delle interfacce, dovrebbe essere iniettato anche se la classe in questione non registra nulla al momento - l'alternativa sarebbe che quando scopri a un certo punto che ora devi registrare qualcosa da questa classe, hai bisogno di un logger, quindi è necessario aggiungere un parametro costruttore per DI, interrompendo tutto il codice client. Non mi piacciono entrambe queste opzioni e ritengo che usare DI per la registrazione complicherebbe la mia vita solo per rispettare una regola teorica, senza alcun beneficio concreto.

Quindi la mia conclusione è: una classe che viene utilizzata (quasi) universalmente, ma non contiene uno stato rilevante per la tua app, può essere tranquillamente implementata come Singleton .

Riguarda principalmente, ma non interamente, i test. I single erano popolari perché era facile consumarli, ma ci sono una serie di svantaggi nei singleton.

• Difficile da testare. Significa come posso assicurarmi che il logger faccia la cosa giusta.
• Difficile da testare. Significa che se sto testando un codice che utilizza il logger, ma non è l'obiettivo del mio test, devo comunque assicurarmi che il mio ambiente di test supporti il ​​logger
• A volte non vuoi un singolo, ma più flessibilità

DI ti dà il facile utilizzo delle tue classi dipendenti - basta inserirlo negli argomenti del costruttore e il sistema te lo fornisce - mentre ti offre la flessibilità di test e costruzione.

L'unica volta in cui dovresti usare un Singleton invece di Dependency Injection è se Singleton rappresenta un valore immutabile, come List.Empty o simili (assumendo elenchi immutabili).

Il controllo dell'intestino per un singleton dovrebbe essere "starei bene se questa fosse una variabile globale invece di un singleton?" In caso contrario, stai utilizzando il modello Singleton per carta su una variabile globale e dovresti considerare un approccio diverso.

Ho appena controllato l'articolo di Monostate: è un'alternativa elegante a Singleton, ma ha alcune proprietà strane:

class Mono{
    public static $db;
    public function setDb($db){
       self::$db = $db;
    }

}

class Mapper extends Mono{
    //mapping procedure
    return $Entity;

    public function save($Entity);//requires database connection to be set
}

class Entity{
public function save(){
    $Mapper = new Mapper();
    $Mapper->save($this);//has same static reference to database class     
}

$Mapper = new Mapper();
$Mapper->setDb($db);

$User = $Mapper->find(1);
$User->save();

Non è questo tipo di paura - perché il Mapper dipende davvero dalla connessione al database per eseguire save () - ma se un altro mapper è stato creato in precedenza - può saltare questo passaggio per acquisire le sue dipendenze. Sebbene sia pulito, è anche un po 'disordinato, no?

Esistono altre alternative a Singleton: modelli Proxy e MonoState.

http://www.objectmentor.com/resources/articles/SingletonAndMonostate.pdf

Come può essere utilizzato il modello proxy per sostituire un singleton?