Programming Languages Hacks

Importanti regole per linguaggi di programmazione rilevanti come Java, C, C++, C#…

  • Subscribe

  • Lettori

    I miei lettori abituali

  • Twitter

Problemi del Dependency Injection: come migliorarlo?

Posted by Ricibald on October 11th, 2013

Le dipendenze dovrebbero essere ridotte per quanto possibile e seguire principi di basso accoppiamento e alta coesione.

Per aiutare questo nasce il pattern Inversion of Control e i vari framework di Dependency Injection, che consentono di mantenere astratte le dipendenze per poter sostituire i vari “blocchetti” a piacimento. Spesso è un prerequisito fondamentale ai test automatizzati unitari.

Problemi dell’IoC (DI)

Problema 1: troppa astrazione

Mantenere un’astrazione troppo elevata non è sempre un bene e potrebbe creare in realtà problemi al codice.
Spesso chi usa framework di DI rende qualunque dipendenza astratta (così stiamo riscrivendo il framework base!), in realtà dovrebbero esserlo solo quelle poche dipendenze di cui sappiamo che ci sarà una sostituibilità (per es. per i test) e per il resto ricordarsi sempre di seguire le buone regole Object Oriented e relativi Design Pattern (Strategy, Decorator, Adapter).

Ricordarsi buone regole di OO e Design Patern significa quindi ad es. implementare il pattern Strategy utilizzando il container IoC poiché altrimenti nel pattern il Context non istanzierebbe lui il ConcreteStrategy, alterando così un pattern consolidato. Il DI serve solo a risolvere le dipendenze non a implementare pattern. Detto in altri termini:

Il DI non sostituisce la buona POO e relativi Design Pattern!

Se si guarda bene, in realtà, il DI richiede che si abbia anche maggiore competenza nella programmazione OO poiché apre le porte a errori grossolani che normalmente verrebbero segnalati dal compilatore. Ad es. i riferimenti circolari non farebbero nemmeno compilare il progetto, ma se in un progetto abbiamo interfacce disaccoppiate tra loro e in un altro progetto le relative implementazioni, in un classico 3-layer potenzialmente il layer infrastruttura potrebbe invocare un metodo del layer presentation (OMG!).

Nota 1: il bisogno reale dell’astrazione

Il DI spinge come abbiamo detto a un’eccessiva astrazione: immagina di voler definire un’interfaccia ILog. Deve essere astratta, quindi indipendente dalla tecnologia e dalla destinazione, giusto? Se questi sono i criteri rischiamo di definire un’interfaccia ILog eccessivamente complessa quando tutto quello che dobbiamo fare è… loggare!

Sei d’accordo con il ragionamento? Concettualmente è valido vero? Ma nel componente ILog dell’esempio in realtà è un ragionamento sbagliato: bisogna fare un discorso più articolato.

Cercando di ricavare una regola, è necessario creare astrazioni (aumentandone quindi la complessità) se:

  • si deve sostituire completamente l’implementazione interna di un componente con un’altra implementazione completamente funzionante
  • si potrebbe sostituire completamente l’implementazione interna di un componente con un’altra implementazione completamente funzionante e tale componente viene invocato in tanti punti

Quindi se ad es. abbiamo un componente SecurityChecker acceduto solo alla login tutto sommato non ha senso astrarlo: andiamo sul concreto e se cambierà implementazione (da DB a LDAP) cambierà anche il contratto esposto dal componente. Richiederà il refactoring in un singolo punto: la login page, ma non sarà un grosso problema e ci saremo risparmiati tanta complessità in più.

Se viceversa abbiamo un componente ILog questo sarà utilizzatissimo in tutti i punti dell’applicazione. Avere un’interfaccia stabile è importantissimo o si pagherà la penalità di un refactoring costosissimo. Per tali componenti avere un’interfaccia astratta è fondamentale.

Se invece abbiamo un componente SecurityCheckerMock o SecurityCheckerStub è vero sì che sostituisce l’implementazione, ma tale sostituzione non ha pretese di essere completa. Per questo si possono evitare astrazioni e costruire un SecurityCheckerMock che semplicemente eredita da SecurityChecker.

Se infine abbiamo un’applicazione multipiattaforma che deve supportare diverse modalità di autenticazione (LDAP, OAuth, DB) allora nel componente SecurityChecker siamo costretti a definire un’interfaccia abbastanza astratta da comprendere le varie implementazioni.

Nota 2: Bottom-Up o Top-Down?

Attenzione a non cadere nella trappola di mantenersi eccessivamente generici anche laddove sia richiesto di sostituire completamente l’implementazione. Questa la regola che ho imparato:

È più efficace modellare (se serve) l’astrazione da casi concreti (Bottom-Up e Agile) che ipotizzare scenari astratti che prima o poi faranno i conti con la realtà (Top-Down)

Facciamo un’esempio, sperimentato in progetti reali: immaginiamo di dover implementare un ContactProvider che esegue il CRUD dei contatti di un generico provider (es. rubrica personale, Google, Facebook, Twitter, …). Se seguiamo l’approccio Top-Down partiremo dalla implementazione astratta: integreremo OAuth e gestioni generiche che prescindono dalla specifica implementazione. Quando però faremo i conti ad esempio con il Provider Google potremmo scoprire che abbiamo scritto tantissimo codice che in realtà non soddisfa la paginazione che Google pretende e che non avevamo immaginato. Risultato finale? Lavoro di giorni e giorni, tante righe di codice “morto” e ancora non abbiamo realizzato una “semplice” integrazione con Google. Sarà una soluzione corretta dal punto di vista accademico, ma non è efficace e paga il costo delle metodologie tradizionali come il modello waterfall.

Diverso è dire: partiamo da un’implementazione concreta (Google) e ci disinteressiamo di astrarre il problema. Quando in futuro (se servirà) dovremo integrare anche Facebook faremo un refactoring per mettere in comune le parti (principio DRY).
Questo approccio aderisce al modello Bottom-Up ed è in linea con la metodologia Agile e con il principio KISS e YAGNI.

Questo approccio anche se sembra essere più costoso (si paga il costo di refactoring) in realtà risulta efficace poiché non avremo dead code e il 100% del codice risulterà effettivamente utilizzato (a maggior ragione se si combina con un approccio TDD).

Nota 3: quanta sostituibilità?

La prima regola appena citata nel creare astrazioni:

si deve sostituire completamente l’implementazione interna di un componente

Apre però uno scenario un po’ preoccupante nel mondo del TDD.

Si consideri la seguente classe, che fa internamente uso di WebClient, XmlSerializer e DateTime.Now per ottenere da un’url remota l’ultima Person salvata da una certa data:

public class Application : IApplication {
    public void GetLastUpdatedPerson() {
        WebClient webClient = new WebClient();
        string lastUpdateDate = DateTime.Now.ToString();
        string personXml = webClient.DownloadString("http://api.myapp.com/person?lastUpdateDate=" + lastUpdateDate);

        XmlSerializer xmlSerializer = new XmlSerializer(typeof(Person));
        using (TextReader reader = new StringReader(personXml))
        {
            return (Person)xmlSerializer.Deserialize(reader);
        }
    }
}

Per abilitare il TDD e quindi la testabilità unitaria della classe Application saremmo obbligati a rimpiazzare tutte le dipendenze con relative astrazioni sostituibili:

public class Application : IApplication {
    private IPersonService _networkManager;
    private ISerializationManager _serializationManager;
    private IDateManager _dateManager;

    public Application(INetworkManager networkManager, ISerializationManager serializationManager, IDateManager dateManager) {
        _networkManager = networkManager;
        _serializationManager = serializationManager;
        _dateManager = dateManager;
    }

    public void GetLastUpdatedPerson() {
        string lastUpdateDate = _dateManager.Now.ToString();
        string personXml = _networkManager.DownloadString("http://api.myapp.com/person?lastUpdateDate=" + lastUpdateDate);
        return _serializationManager.Deserialize<Person>();
    }
}

Questo però significa che in proiezione andremo a wrappare l’intero framework con interfacce sostituibili. Niente da dire, è un approccio formalmente corretto ma rischiamo di aggiungere veramente troppo codice per testare solo che la classe Application coordina correttamente le chiamate passando i parametri giusti: bisogna sempre pesare costi (quanto lavoro e complessità aggiungo) con relativi benefici (“quanto” si testa).

La mia opinione è questa: il software è composto da classi, da moduli e da layer. Secondo me gli unit test puri, che vanno a testare in modo isolato le singole classi, vanno ad aggiungere troppo overhead per consentire la sostituibilità effettiva di tutte le dipendenze.

Molto meglio testare in isolamento i singoli moduli o layer: ha quindi senso costruire un’astrazione attorno al layer di Persistence per testare in isolamento la coppia di layer Application e Domain. O ha senso costruire dei test per la nostra personale libreria di deserializzazione che poi verrà utilizzata direttamente, senza interfacce.

Inoltre ci si dimentica che spesso non si ha un reale bisogno di sostituire l’implementazione: basta configurare l’ambiente in modo opportuno. Prima di un test si possono ad esempio impostare realmente chiavi di configurazione, valori di sessione, condizioni a contorno, web service dummy, database da snapshot, orario del sistema operativo, snapshot di virtual machine con stati “interessanti”. Non bisogna esagerare né nella configurazione (si appesantisce preparazione ed esecuzione dei test) né nella sostituzione (si riscrive il framework), è necessario il giusto compromesso, risultato di tanta esperienza e di tanto refactoring!

Problema 2: l’applicazione, andando nel “concreto”… come diavolo funziona??

Ragionare logicamente su un codice le cui relazioni sono implicitamente legate attraverso configurazioni esterne sottopone a indirezioni in più che ostacolano il lavoro quotidiano. È come se il codice che vediamo avesse una dimensione in più, comprensibile solo ispezionando la configurazione delle dipendenze. Facendo una metafora, basta notare che i siti di e-commerce spesso cercano di ottenere un’esperienza di acquisto “one-click” perché aggiungere un ostacolo a tale processo può compromettere l’acquisto stesso. Per il codice è lo stesso: senza un’esperienza “one-click” per navigare il codice (stile CTRL+Click come Resharper o Eclipse) si rischia di ottenere un complessivo peggioramento della produttività.

L’effetto finale è che risulta complicato seguire il giro finale. Spesso l’unico modo che rimane per capire cosa fa praticamente il codice è… eseguirlo!

Se il codice senza DI è uno Spaghetti Code, il codice con DI diventa in questo modo un Ravioli Code: le classi sono sì disaccoppiate, ma per legarle logicamente tra loro bisogna ricostruire il giro, riproducendo a mente lo stesso Spaghetti Code di prima. In pratica, se le dipendenze sono troppe, potremmo arrivare a un raviolo con un ripieno di tanti spaghetti…

Problema 3: troppa frammentazione

Altro problema è che per ottenere un reale disaccoppiamento tramite DI saremo costretti a definire tante piccole interfacce con relative implementazioni. Sebbene questo sia formalmente valido, applicare buone tecniche nei posti sbagliati può far calare la produttività: far confluire più concetti nella stessa singola classe, sebbene diminuisca la coesione, può risultare per certi scenari più produttivo. Si pensi ad es. a una formula matematica complessa: una cosa è leggere la formula in un unico posto, un’altra è distrecarsi tra vari componenti interdipendenti (e astratti!).

Problema 4: chi istanzia le classi?

Se andiamo a leggere un codice tipico che fa uso di framework di DI:

public class Application : IApplication {
    private IPersonService _personService;

    public Application(IPersonService personService) {
        _personService = personService;
    }

    public void AddPerson(Person person) {
        _personService.Add(person);
    }
}

Il costruttore ottiene da qualcuno un’istanza di IPersonService. Prova a chiedere al tuo IDE chi invoca il costruttore. Come dici? Nessuno invoca il costruttore? L’IDE non è infatti in grado di determinare staticamente chi istanzierà IApplication. Questo complica sia la comprensione del giro, sia l’analisi statica del codice.

Problema 5: trappole nel ciclo di vita delle variabili

Grazie al DI è possibile configurare il ciclo di vita delle istanze. Possono essere Singleton, transient (ogni volta ricreate), thread-scope (legate al thread), request-scope (legate alla richiesta web).

Si veda lo snippet di codice precedente. Piccolo quiz: se IPersonService ha ciclo di vita thread-scope (legato al thread), quando si invoca AddPerson la variabile _personService sarà ricreata quando cambia il thread?

La risposta è… dipende dal ciclo di vita di Application:

Application Scope dichiarato _personService Scope effettivo
Transient Thread-Scope
Thread-Scope Thread-Scope
Singleton Singleton

Se Application è Singleton non importa come è configurato lo scope di IPersonService poiché una volta istanziata Application non verrà mai più risolto. Se quindi IPersonService porta con se uno stato (che dovrebbe essere legato al thread) in questo modo tale stato potrebbe essere invece Singleton, causando un effetto collaterale veramente ostico da rilevare.

Problema 6: analisi statica del codice

Se utilizziamo strumenti di analisi statica del codice come Visual Studio Code Metrics, NDepend o Nitriq otteniamo risultati sfalsati che si rileveranno migliori della realtà effettiva. Se ad es. abbiamo:

  • due interfacce: IPresentation e ICrossComponents. La direzione dovrebbe ovviamente essere: IPresentation vede ICrossComponents (mai viceversa)
  • due implementazioni iniettate: Presentation e CrossComponents
  • uno sviluppatore (moooolto junior) nel costruttore di CrossComponents inietta IPresentation
  • otteniamo un riferimento circolare (!)

Nella pratica avremo un riferimento circolare e un codice scritto male. Ma nei risultati dell’analisi questo non emergerebbe: le due classi Presentation e CrossComponents risulterebbero come mai usate e quindi verrebbero escluse dall’analisi mentre le due interfacce IPresentation e ICrossComponents risulterebbero autonome quando in realtà creano un riferimento circolare.

Si noti che lo stesso problema si ha per:

  • la compilazione: avremo molti warning che in realtà non sono veri problemi, portando presto a ignorare qualunque warning
  • il code analysis di Visual Studio genererebbe molti warning che in realtà non lo sono, costringendoci a ignorare tali warning e, alla lunga, a precluderci i benefici del code analysis in generale
  • i progetti di architettura, che hanno il compito di validare la comunicazione tra i layer, non sarebbero in grado di rilevare il codice che non rispetta i vincoli architetturali stabiliti
  • il Full Analysis di Resharper indicherà che molte classi non sono mai usate, rendendo lo strumento meno potente e a volte anche scomodo
  • il test impact analysis basato su analisi statica (sebbene quelli di Microsoft si basino invece da una baseline di test eseguita)
  • il nuovo CodeLens di VS2013 che si basa su analisi statica per offrire popup informative su metodi per mostrare relativi test e utilizzi
  • poiché molti IoC/DI si basano su configurazione dinamica delle dipendenze, il dead code elimination (come Resharper, Telerik, SmartAssembly o MonoLinker) rileverebbero codice non utilizzato che in realtà verrebbe caricato tramite reflection. I tool non sarebbero usabili.
  • poiché molti IoC/DI si basano su configurazione dinamica delle dipendenze, la pratica di obfuscation (tramite DotFuscator o SmartAssembly) rinominerebbero le classi che contengono le implementazioni, le quali non sono poi più ritrovabili in fase di ottenimento della classe dal container IoC/DI

Questi problemi sono tutti presenti se si usa un framework IoC/DI basato su configurazione (es. Unity). Quelli invece basati su compilazione tramite generics (es. Ninject) non soffrono di alcuni di questi problemi poiché il compilatore “sa” che le implementazioni verranno prima o poi utilizzate.

Problema 7: Design by Contract (DbC) non verificabile

Il Design By Contract si basa sull’idea che l’interfaccia debba funzionare correttamente solo se i chiamanti invocano tale interfaccia in modo corretto e che l’interfaccia non debba quindi ridondare la verifica di condizioni che già devono aver verificato i chiamanti. Il DbC è opposta al Defensive Programming in cui l’onere della verifica è invece del servente, non del chiamante.

Erroneamente si tende a pensare che quando si ha un’interfaccia automaticamente si ha un contratto, in realtà non è così. Per avere un contratto devono essere documentate e, se possibile, verificate automaticamente le caratteristiche corrette di input, precondizioni, postcondizioni e invarianti.

Esistono diversi sistemi per abilitare la verifica automatica dei contratti. La soluzione Microsoft per questo si chiama Code Contract e consente sia una verifica dinamica sia una verifica statica, cioè a tempo di compilazione.

Esempio pratico:

public class Main {
    public static void Main() {
        IoC myContainer = GetConfiguredIoC();
        IApplication app = myContainer.Get<IApplication>();
        app.AddPerson(null);
    }
}

public class Application : IApplication {
    private IPersonService _personService;

    public Application(IPersonService personService) {
        _personService = personService;
    }

    public void AddPerson(Person person) {
        Contract.Requires(person != null);
        _personService.Add(person);
    }
}

Guardando il codice, il metodo AddPerson viene invocato passando null e quindi il chiamante sta violando il contratto. Nonostante questo, l’errore non verrà segnalato a tempo di compilazione, poiché in realtà Main staticamente non sa che la classe sarà Application e quindi non può analizzare staticamente le relative precondizioni.

Ora potremmo anche stare a discutere dei limiti dei Code Contract ma fare retorica non risolve i limiti dei framework a cui dobbiamo adeguarci. La lezione da capire è semplicemente che molti tool che aiutano la produttività hanno bisogno di conoscere le dipendenze in modo statico e molti di questi tool sarebbero inevitabilmente penalizzati.

Problema 8: prestazioni

Avere tanti concetti indipendenti significa non doverci legare all’una o l’altra tecnologia. Se vogliamo fare le cose pulite, significa avere ad es. un progetto MyProject.Persistence con le interfacce e progetti con le implementazioni: MyProject.Persistence.InMemory, MyProject.Persistence.MySql, MyProject.Persistence.SqlAzure. Questo poiché se utilizziamo MySql come persistence non vogliamo portarci dietro le dll di Azure.

Il risultato è avere tanti progetti in VS e tante dll relative. Il progetto finale “reale” non avrà le reference a tutte le dll ma solo a quelle effettivamente necessarie (es. Persistence.MySql) mentre il progetto di “test” avrà le reference verso altre dll (es. Persistence.InMemory).

Il problema non è avere tanti progetti ma è la strategia di compilazione di VS (cioè di MSBuild). Il linguaggio C funziona come dovrebbe: ricompila solo le classi effettivamente impattate da una modifica. In linguaggio C, se quindi ho X che usa Y che usa Z e viene modificata l‘implementazione di Z (ma non l’interfaccia) il compilatore ricompila solo Z lasciando inalterato Y che si basa su un’interfaccia non modificata. Se invece viene alterata l’interfaccia di Z ricompila solo Y lasciando inalterato X. Questo significa che se nel kernel linux si va a modificare l’implementazione network.c la compilazione sarà immediata poiché l’interfaccia non è stata alterata. Una compilazione in un secondo, in un progetto di milioni di righe…

Come funziona invece VS? Se siamo nell’ambito dello stesso progetto… buone notizie, VS compila in modo efficiente seguendo (più o meno) gli stessi principi del compilatore C. Se però si tratta di progetti diversi… facciamo un esempio. Ho tre progetti: X che referenzia Y che referenzia Z e viene modificata l’implementazione di una classe di Z (ma non l’interfaccia): il compilatore ricompila Z e, a cascata, ricompilerà Y e X (!!!).

Nella pratica, se modificherò un dettaglio implementativo del progetto Infrastructure a cascata verranno ricompilati tutti i numerosi progetti che il Dependency Injection mi ha “obbligato” a definire. La ricompilazione può essere anche molto lunga se utilizziamo tool di postcompilazione (come PostSharp) o tool di analisi statica del codice (come i Code Contract) o tool di produttività personale (come Resharper).

Definire tanti progetti ha i suoi vantaggi (es. separazione delle parti e rimpiazzabilità della dll) ma spesso non ben compresi (se rimpiazzo una dll devo rimpiazzare anche le dipendenti?). Avere tante dll in un progetto con IoC/DI diventa quasi un obbligo ma il costo in termini di produttività quotidiana potrebbe essere alto.

Un “nuovo” approccio: sostituzione statica

Ora ragioniamo su un punto… ma è sempre stato così? Come veniva scritto il kernel di Linux?

Ricordiamo che “ai tempi” avevamo l’header file bluetooth.h e il relativo file bluetooth.c.
Il file bluetooth.h contiene i prototipi delle funzioni e il file bluetooth.c contiene le relative implementazioni. Questo significa che se kernel.c fa uso di bluetooth.h allora le funzioni invocate faranno uso dell’implementazione trovata in bluetooth.c. Ma se invece siamo in un sistema a 64 bit il kernel di Linux potrebbe compilare invece il file `bluetooth_64bit.c.

Questo significa, portandolo nel nostro mondo OO, che gli header file sono le nostre interfacce e i file .c sono le nostre implementazioni. Cosa cambia rispetto ai framework IoC-DI? Due semplici cose:

  1. la tecnica esisteva dal 1972 (!)
  2. avveniva tutto a tempo di compilazione

Il punto focale è l’ultimo: avveniva tutto a tempo di compilazione. Pensiamoci bene: rimpiazzare IApplication con ApplicationMock può essere utile per i test, ma non c’è bisogno che sia dinamico, può essere risolto a tempo di compilazione.

Come fare a ottenere questo? In due modi:

  1. sostituendo dll che mutano la risoluzione dinamica del tipo
  2. sostituendo il codice compilato internamente tramite direttive di compilazione condizionata

La prima soluzione diventerebbe:

// FILE Main.CS in Console.dll
public class Main {
    public static void Main() {
        Application app = new Application();
        app.AddPerson(person);
    }
}

// FILE Application.cs in Application.dll dal progetto Application.Real
public sealed class Application {   // real implementation
    public void AddPerson(Person person) {
        PersonService personService = new PersonService();
        personService.Add(person);
    }
}

// FILE Application.cs in Application.dll dal progetto Application.Mock
public sealed class Application {   // mock implementation
    public bool AddPersonInvoked { get; set; } 
    public void AddPerson(Person person) {
        this.AddPersonInvoked = true;
    }
}

Se la cartella che contiene l’applicazione contiene i seguenti file:

  • Console.dll
  • Application.Mock.Dll

Allora il tipo Application risolto sarà quello con implementazione Mock,

La seconda soluzione tramite direttive di compilazione condizionata diventerebbe invece:

// FILE Bootstrap_Prod.cs (compilato solo in compilation mode RELEASE)
#DEFINE REAL
#DEFINE REPOSITORY_IN_DATABASE
#DEFINE SECURITY_IN_LDAP

// FILE Bootstrap_Test.cs (compilato solo in compilation mode TEST)
#DEFINE MOCK
#DEFINE REPOSITORY_IN_MEMORY
#DEFINE SECURITY_IN_MEMORY

// FILE Main.CS
public class Main {
    public static void Main() {
        Application app = new Application();
        app.AddPerson(person);
    }
}

// FILE Real\Application.cs
#IF REAL
public sealed class Application {   // real implementation
    public void AddPerson(Person person) {
        PersonService personService = new PersonService();
        personService.Add(person);
    }
}
#ENDIF

// FILE Mock\Application.cs
#IF MOCK
public sealed class Application {   // mock implementation
    public bool AddPersonInvoked { get; set; } 
    public void AddPerson(Person person) {
        this.AddPersonInvoked = true;
    }
}
#ENDIF

Notato qualcosa? Non ci sono più interfacce!! Se il progetto viene compilato in modalità RELEASE allora il file Bootstrap_Prod.cs viene incluso e il file compilato sarà Real\Application.cs. La classe Main quando istanzia Application otterrà la versione reale senza alcun bisogno di DI. Il giro funziona bene finquando le due classi REAL e MOCK hanno lo stesso fullname (devono quindi dichiarare lo stesso namespace).

Confrontando le due soluzioni la separazione fisica delle dll è la soluzione più semplice, ma meno flessibile rispetto a quella basata su compilazione condizionata, dove è possibile definire molti attributi che consentono di configurare a tempo di compilazione in modo molto puntuale l’implementazione da fornire.

Vantaggi dell’approccio a sostituzione statica

L’approccio abilita la stessa sostituibilità di implementazione del DI con i seguenti vantaggi:

  • il codice è facilmente navigabile (CTRL+Click)
  • la leggibilità del codice è diretta
  • la costruzione delle istanze è diretta
  • il ciclo di vita delle istanze è semplice da seguire
  • l’analisi statica del codice produce risultati veritieri, diventando uno strumento utile alla qualità del codice
  • i progetti di architettura possono validare il codice
  • errori grossolani come riferimenti circolari sono ora impediti
  • il codice è più performante poiché non ha l’indirezione del container IoC

Purtroppo l’approccio ha anche i suoi svantaggi

Problema 1: disallineamento (solo con la compilazione condizionata)

Il punto forte e il problema al tempo stesso è che viene compilato solo il codice interessato: questo potrebbe portare a non compilare per tanto tempo la versione MOCK con forti rischi di disallineamento. Inoltre strumenti di refactoring andrebbero a propagare i cambiamenti solo nelle parti attualmente compilate.

In questo caso è necessario avere un meccanismo che compili automaticamente nelle varie configurazioni. È sufficiente scrivere un semplice script di build tramite MSBuild o NAnt che genera i diversi binari nelle varie configurazioni e includerlo in un processo automatico di verifica.

Si noti che questo problema si presenta solo con la seconda soluzione (tramite direttive di compilazione condizionata). Nella prima soluzione semplicemente si andrà a creare un pacchetto che avrà o meno una certa dll, ma potranno essere sempre tutte compilate.

Problema 2: rimpiazzare con mock

L’approccio funziona bene con gli stub (implementazioni complete, come repository in memoria) ma funziona male con i mock (implementazioni specifiche del test per forzare un certo comportamento della dipendenza).

I framework di mocking, come Moq, funzionano generando dinamicamente implementazioni “al volo” di interfacce. Spesso questi framework chiedono di poter lavorare su un’interfaccia pura e solo i framework più evoluti possono lavorare con una classe concreta i cui metodi siano ridefinibili da una sottoclasse (virtual). Questo porcherebbe a sporcare tutte le classi con vari virtual in tutti i metodi.

Inoltre non basta riuscire a definire il mock, bisogna anche passarlo nel metodo che si sta testando. Senza IoC la dipendenza non è esternalizzata e non la possiamo impostare, poiché viene costruita all’interno del metodo stesso. In questo caso l’unico modo è fare, come nell’esempio precedente, una vera e propria implementazione mock. Per diminuire il lavoro ripetitivo si può generare il codice tramite T4 Text Templates o creando shim tramite framework molto particolari come Microsoft Fakes.

Problema 3: riuso delle istanze

A volte riusare la stessa istanza all’interno del codice è utile ed esiste il pattern Singleton per questo. Il problema è che il Singleton presenta forti problemi legati al testing e alla concorrenza e rappresenta una scelta architetturale molto vincolante che rende invasivo l’eventuale cambio di rotta.

Per questo si dovrebbe usare un container che abiliti il riuso della stessa istanza. Ragionando in questo modo rischiamo però di avvicinarci progressivamente a una versione “lite” del pattern IoC da cui cerchiamo di allontanarci.

LA SOLUZIONE: Dependency Injection senza interfacce

Bilanciando pro e contro il problema non è tanto la presenza di un framework DI, che ha numerosi vantaggi, quanto il fatto di puntare sempre, ovunque, verso interfacce e astrazioni invece di classi concrete.

La soluzione è scegliere un approccio misto: IoC+DI che non lega verso interfacce ma verso classi concrete costruite o (prima soluzione) in dll differenti o (seconda soluzione) tramite compilazione condizionata*.

Il codice diventa quindi qualcosa del genere:

// FILE Main.CS
public class Main {
    public static void Main() {
        IoC myContainer = GetConfiguredIoC();
        Application app = myContainer.Get<Application>();
        app.AddPerson(person);
    }
}

// FILE Real\Application.cs
#IF REAL
public class Application {  // real implementation
    private PersonService _personService;

    public Application(PersonService personService) {
        _personService = personService;
    }

    public virtual void AddPerson(Person person) {
        _personService.Add(person);
    }
}
#ENDIF

In questo modo si ottengono i vantaggi da entrambi i mondi, possono essere definiti mock con Moq ed essere facilmente testati. L’unico svantaggio che rimane è il virtual necessario a ogni metodo, ma questo è facilmente eliminabile in RELEASE aggiungendo uno step di build personalizzato.

Conclusioni

Le nuove tecniche emergenti TDD, DDD, IoC e DI devono essere valutate in modo critico solo dopo averle conosciute bene. Dopo averle conosciute e averci lavorato mi sento di consigliare l’approccio IoC e DI per i vantaggi sulla testabilità e sul controllo del ciclo di vita delle variabili. Ma mi sento di sconsigliare l’indirezione tramite interfacce che crea problemi sulla leggibilità e sull’analisi statica del codice.

Per questo motivo il compromesso DI+IoC+ClassiConcrete ottenuto tramite separazione dll o compilazione condizionata sembra bilanciare bene i vantaggi di ogni tecnica, facendo tornare “in auge” tecniche che risalgono a 40 anni fa.

Leave a Reply

You must be logged in to post a comment.