Nel post precente ho introdotto cosa si intende per SOLID e cosa ci “azzecca” IoC.

In estrema sintesi la regola D relativa a SOLID (DIP = Dependency Inversion Principle) può essere rispettata usando il pattern Ioc Inversion Of Control, in una delle sue due varianti: Dependency Inversion o Service Locator.

Il questo post verrà descritta la prima variante (Dependency Injection) che ritengo essere il metodo più semplice per implementare il pattern IoC e quindi risolvere il principio Dependency Inversion Principle (DIP).

Ricordo questo principio (esemplificando) afferma che non dovrebbero esistere due pezzi di codice che dipendono direttamente l’uno dall’altro.

Nel nostro esempio abbiamo la classe DirectoryController che dipende pesantemente dalla classe LogWriter e dalla classe LogWriterOnEventViewer.

In definitiva ecco l’implementazione.

---

La classe DirectoryController non dipenderà più dalle classi delegate a scivere il messaggio di log, ma dall’interfaccia.

Quindi la corretta classe che deve essere utilizzata viene passata nel costruttore, e sarà utilizzata correttamente all’interno dei metodi.

Osservo che in questo caso abbiamo usato il costruttore, ma potrebbe essere utilizzato anche un metodo o una proprietà della classe DirectoryController: in tal caso si avrebbe il vantaggio di poter cambiare la classe logger dinamicamente.

Ritengo comunque che queste siano variazioni sul tema abbastanza trascurabili: il concetto da tenere presente è che qui la classe non è più legata alla classe utilizzata per i logging, bensì alla sua interfaccia.

Quindi la classe utilizzata per il logging può essere qualsiavoglia: basta che rispetti la regola di implementare l’interfaccia ILogger.

Aggiungo che usando il metodo sopra è possibile sviluppare tutto senza avere il codice sorgente della classe di logging: questa potrà essere caricata dinamicamete alla bisogna in fase di runtime.

Nel prossimo post completeremo questa descrizione, ma direi che già con questa modifica siamo molto avanti !