Ioc: e adesso ciak

marco mangia — Fri, 11 Sep 2009 12:34:40 GMT

Ecco la versione video dell'articolo pubblicato qui . Ho inserito qualche vignetta di Scott Adams che sono riuscito a trovare in giro, modificandola. Dilbert che esce fuori dal suo cubicle e finisce su una ppt..

NB:

non sono uno speaker professionista !!
a causa di settaggi forse errati, stiamo cercando di capire il problema di alcune distorsioni
volevo ringraziare Igor per l'incoraggiamento

Qui le slides: Dependency Inversion Principle

IoC: maccheroni per programmatori procedurali

marco mangia — Wed, 09 Sep 2009 17:28:03 GMT

In questo primo articolo darò un'introduzione "infantile" al concetto di Inversion of Control(IoC) ed ad una sua implementazione tramite il pattern di Dependency Injection(DI). Sebbene IoC e DI siano considerati sinonimi, mi è sembrato di capire che DI sia una implementazione particolare di IoC, a mano o tramite framework. Comuque, qui non farò riferimento a framework particolari, ma solo al principio di base che dovrebbe condurci a scrivere codice a basso accoppiamento (low coupling).

Per una mia innata prigrizia, mi piace di più usare le immagini per fissare i concetti. Non sto qui ad elencare i motivi biologici.

Già, chi collegherebbe una lampada saldandola ai cavi elettrici nella parete ? A patto che abbia voglia di vincere il premio Darwin di quest'anno. Il problema è che non sono sicuro del risultato finale ...

DIP in pratica ci spinge a utilizzare e dipendere da interfacce (o astrazioni). Quasi non c'è più niente da dire, vista la banalità della cosa. Pigro sì, ma pragmatico:

Nessuna classe dovrebbe derivare da un tipo concreto
Nessuna variabile dovrebbe avere un riferimento ad un tipo concreto
Nessun metodo dovrebbe fare l'override di un metodo implementato in qualcuna delle sue classi base

Altre due imaginette ci aiutano a capire ancora meglio:

Nella prima una classe consumer ha delle dipendenze con le classi concrete, ovvero ha il comp ci creare uno dei tre tipi facendo ricorso all'operatore new

E' il caso appunto in ciui componenti ad alto livello dipendono da componenti a basso livello

Il verso della dipendenza imita molto quello della tipica programmazione procederale

public class Dependent
{
    public IDependent _dependent;
    public void DoSomething(string dependent)
    {
        if (dependent.EndsWith("1"))
            _dependent = new DependentClass1();
        if (dependent.EndsWith("2"))
            _dependent = new DependentClass2();
        if (dependent.EndsWith("3"))
            _dependent = new DependentClass3();
        _dependent.DoSomethingInDependent();
    }
}

La seconda invece ci mostra gli effetti della cura dopo aver implementato DIP:

L'iniettore della dipendenza stesso dipende da una astrazione (classe abstract o tipo interface). Ovvero possiede un riferimento all'interfaccia tramite un campo privato

Così i tipi concreti che derivano dall'interfaccia, implementandola

Il verso della dipendenza si è invertita, da questo il nome di Inversione di Controllo (mesi fà mi dicevo: inversione de che ??)

    public class Injector
    {
        private IDependent _dependent;
        public IDependent Dependent
        {
            get { return _dependent; }
            set { _dependent = value; }
        }
        public void DoSomething()
        {
            Dependent.DoSomethingInDependent();
        }   
    }

Persino il class diagram, uhh:
Martin Fowler in suo famosissimo articolo ci insegna 3 tipi di DI:

Iniezione tramite metodi d'interfaccia di Tipo 1
Iniezione tramite proprietà di Tipo 2
Iniezione tramite costruttore di Tipo 3

La prima è quella che obbliga a definire un'interfaccia (da non confondersi con l'astrazione necessaria al DIP) , dalla quale poi l'iniettore dovrà derivare, constringendolo ad implementare i metodi
La seconda invece è la proprietà che si preoccupa di valorizzare il campo privato che rappresenta la dipendenza verso l'interfaccia
La terza invece è quella in cui, il riferimento viene risolto nel momento in cui l'iniettore viene creato, dovendolo passare come parametro.

Forse Martin si era sparato tutti i cofanetti di Spielberg prima di scrivere l'articolo, diciamo che non farei una distinzione così ferrea tra tipi, basta capire quando ci servono.
Delle tre, la prima non l'ho mai usata nè vista usare. Dopo tutto devo scrivere del codice in più. Preferisco la seconda e la terza modalità o un misto delle due, poichè mi risulta comodo per lo "state based unit-testing", cioè posso governare e controllare come viene risolta la dipendenza. Userei solo la seconda o al massimo la prima solo quando ho bisogno di posticipare l'iniezione.

Dimenticavo, appena posso mi comprerò questa simpatica magliettina che fa parte della campagna anti-if promossa da xplabs.

E' proprio IoC, uno dei mezzi che ci aiutano in questa battaglia. Non per if stesso ma per un suo abuso, chiaro.

NB: ho fatto anche un versione video, o screencast, di questo articolo. Devo un attimo sistemare il "montaggio". Ho Sergio Leone in chat che mi sta dando dei validi consigli. Lo pubblico più tardi o al max domani mattina.

Design Patterns

Ioc: e adesso ciak

IoC: maccheroni per programmatori procedurali