Giampiero Granatella

Sento tanto parlare di Spring e tanti miei amici, che stimo informaticamente, del JUG lo usano, che mi sono deciso ad approcciarmi a questo framework, anche se da una prima vista, qualche tempo fa, non mi aveva particolarmente colpito.

Alla base di tutto Spring c’è questo concetto dell’Inversion of Control al quale dedico questo post. Benché usatissimo, cosa vuol dire esattamente?

Da quanto comprendo è invertire il punto di vista dell’approccio nello sviluppo di un’applicazione. Cercare di sviluppare in maniera generica (via interfaccia) e isolare in un punto specifico il flusso di controllo (control flow), dove in maniera imperativa vengono specificate le singole procedure o le singole classi che attuano il problema generico ad un singolo contesto.

Quali dovrebbero essere i vantaggi del IoC?

1. La semplicità nello sviluppo
2. maggiore lettura del codice
3. e il più importante di tutto il riuso

Molti affermano che Spring come altri framework, usando IoC vincolano i programmatori alla buona programmazione andando ad utilizzare tutte le potenzialità dell’Object Oriented (eredità e Polimorfismo, …), che altrimenti vengono spesso ignorati portando i linguaggi OO ad essere estrnsioni dei procedurali. Se da un lato mi trovo d’accordo non sono ancora così esperto da dire se l’introduzione di tali framework risolve un problema, ma ne introduce nuovi pradigmi di cattiva programmazione… vedremo.

Ma per i più curiosi a cosa si riporta Spring e gli altri framework che realizzano l’IoC. Toriniamo qualche passo indietro e scopriamo che alla base c’è una soluzione (un Design Pattern) che realizza questi concetti: l’Abstract Factory (già descritto nei design Pattern della GoF).

Facciamo l’HelloWorld dell’Inversion of Control…

Primo scriviamo un interfaccia per i saluti (SalutiIF.java)

pulic interface SalutiIF {

   public void salutami (String name);

}

public class SalutiStdOut implements SalutiIF {

    public void salutami (String name) {

    System.out.println("Ciao "+name);

    }

}

e ora immaginiamo di esserci scritti SalutiWS, SalutiEJB, SalutiSocket, SalutiServlet ecc…

Dove definire le nostre injection (in questo caso il flusso si riduce a dire quale implementazione usare). In spring in un bel (ironico) file XML. Ma in questo caso basta un file di properties. Il factory userà il file di properties e istanzierà la classe concreta (è proprio il punto dove si realizza il Flow Control).

Nel client che chiederà i saluti  non istanzieremo la classe SalutiStdOut, ma ci verrà ritornata attraverso il factory. Il factory sarà un singleton che al suo interno avrà un metodo salutiFactory simile al seguente…

public SalutiIF getSaluti {

 try {

   Properties prop = new Properties();

   prop.load (new FileInputStream ("/ioctest.properties");

   return (SalutiIF) Class.forname(prop.getProperty("saluti")).newInstance();

 }

}

Ho scritto il codice direttamente nel post, quindi magari ci ho messo qualche errore :-), ma credo che con questo esempio mi sia più chiaro e spero anche a voi il concetto di IoC che è  alla base di Spring. E da questo si può passare oltre nello studio…