JJ — n. 3 — marzo-aprile 2007

Programmazione AOP conAspectJdi Mattero Baccan

Dopo anni di programmazione strutturata, si e passati ad anni di programmazione ad og-getti. Ora si inizia a parlare di POP (Post Object Programming), e delle tecnologie correla-te. AOP (Aspect Oriented Programming), e appunto una di queste tecnologie. Vediamodi cosa si tratta, con esempi pratici e l’utilizzo di un compilatore gratuito come AspectJ.

Matteo BaccanE uno specialista diprogettazione e svilup-po C++, JAVA e AOP.E ideatore del por-tale JobCrawler.ite speaker in impor-tanti eventi Java(Javaday, JIP Day).

pubblicato suWWW.INFOMEDIA.IT

!stampa digitale da

Lulu Enterprises Inc.stores.lulu.com/infomedia

InfomediaInfomedia e l’impresa editoriale che da quasi venti an-ni ha raccolto la voce dei programmatori, dei sistemi-sti, dei professionisti, degli studenti, dei ricercatori e deiprofessori d’informatica italiani.Sono piu di 800 gli autori che hanno realizzato per le te-state Computer Programming, Dev, Login, Visual BasicJournal e Java Journal, molte migliaia di articoli tecnici,presentazioni di prodotti, tecnologie, protocolli, strumen-ti di lavoro, tecniche di sviluppo e semplici trucchi e stra-tagemmi. Oltre 6 milioni di copie distribuite, trentamilapagine stampate, fanno di questa impresa la piu grande edinfluente realta dell’editoria specializzata nel campo dellaprogrammazione e della sistemistica.In tutti questi anni le riviste Infomedia hanno vissuto del-la passione di quanti vedono nella programmazione nonsolo la propria professione ma un’attivita vitale e un verodivertimento.Nel 2009, Infomedia e cambiata radicalmente adottandoun nuovo modello aziendale ed editoriale e si e organiz-zata attorno ad una idea di Impresa Sociale di Comunita,partecipata da programmatori e sistemisti, separando leattivita di gestione dell’informazione gestite da un boardcomunitario professionale e quelle di produzione gesti-te da una impresa strumentale. Questo assetto e in lineacon le migliori esperienze internazionali e rende Infome-dia ancora di piu parte della Comunita nazionale deglisviluppatori di software.Infomedia e media-partner di manifestazioni ed eventi inambito informatico, collabora con molti dei piu impor-tanti editori informatici italiani come partner editoriale efornitore di servizi di localizzazione in italiano di testi inlingua inglese.

L’impaginazione automatica di questa rivista e realizzata al100% con strumenti Open Source usando OpenOffice,Emacs, BHL, LaTeX, Gimp, Inkscape e i linguaggi Lisp,Python e BASH

For copyright information about the contents of JavaJournal, please see the section “Copyright” at the endof each article if exists, otherwise ask authors. Infomediacontents is © 2007 Infomedia and released as CreativeCommons 2.5 BY-NC-ND. Turing Club content is© 2007Turing Club released as Creative Commons 2.5 BY-ND.

Le informazioni di copyright sul contenuto di Java Jour-nal sono riportate nella sezione “Copyright” alla fine diciascun articolo o vanno richieste direttamente agli au-tori. Il contenuto Infomedia e © 2007 Infomedia e rila-sciato con Licenza Creative Commons 2.5 BY-NC-ND. Ilcontenuto Turing Club e© 2007 Turing Club e rilasciatocon Licenza Creative Commons 2.5 BY-ND. Si applicanotutte le norme di tutela dei marchi e dei segni distintivi.

E in ogni caso ammessa la riproduzione parziale o tota-le dei testi e delle immagini per scopo didattico purchevengano integralmente citati gli autori e la completaidentificazione della testata.

Manoscritti e foto originali, anche se non pubblicati, nonsi restituiscono.

Contenuto pubblicitario inferiore al 45%.

La biografia dell’autore riportata nell’articolo e sulsito www.infomedia.it e di norma quella disponibi-le nella stampa dell’articolo o aggiornata a cu-ra dell’autore stesso. Per aggiornarla scrivere ainfo@infomedia.it o farlo in autonomia all’indirizzohttp://mags.programmers.net/moduli/biografia

JAVA Journal

54 n.3 - marzo/aprile 2007

focus

Programmazione AOP con AspectJ

Progettare una libreria di funzioni o un framework di classi, è sicuramente un’operazione lunga e laboriosa.Occorre capire i problemi che si avran-no, il modo col quale astrarli e genera-lizzarli, ma soprattutto prevedere, nel

modo più completo possibile, le nuove esigenze che si potrebbero avere, per evitare di trovarsi, durante lo sviluppo, in problemi architetturali.Esistono però delle esigenze orizzontali ad un fra-mework, che dovrebbero far parte di tutte le classi, ma, per evitare di sporcare tutto il codice, si tende a non integrarle, ad integrarle parzialmente, o a dele-garle al programma chiamante.Esempi classici di queste esigenze sono la gestione degli errori, il debug degli oggetti, il controllo formale dei parametri e così via.Cosa vuol dire affrontare in modo generalizzato que-ste problematiche?Sicuramente significa creare dei sorgenti ridondanti, copiare dei frammenti di codice da un metodo all’al-tro, astrarre esigenze in interfacce ed obbligare le classi ad implementarle. Fino ad arrivare agli assurdi delle dipendenze circolari, schemi dai quali diventa complicato uscire.Quando poi l’esigenza orizzontale muta, ne risente l’intero framework, creando delle destabilizzazioni nel codice: se il tutto non è stato progettato più che bene, ci si può trovare di fronte alla riscrittura di varie classi, che non dipendono direttamente dalla modifica della funzionalità orizzontale, ma semplice-mente sono impattate in quanto utilizzatrici dirette della funzionalità ormai obsoleta.

Perché AOP

Lo scopo di AOP è quello di isolare un’esigenza oriz-zontale, racchiuderla all’interno di una regola (as-pect), ed applicarla solamente nei punti in cui serve, senza impattare minimamente la classe che ne trarrà vantaggio.Questo vuol dire che, le persone che sviluppano una classe e quelle che la arricchiscono con un aspect, possono tranquillamente far parte di due team di svi-luppo diversi, dato che lavorano su due set di classi differenti, che si fondono per creare un unico byteco-de, che sarà quello che andrà ad essere utilizzato in fase di runtime.Sorgenti diversi, impatti minimi al cambio delle funzionalità delle classi, possibilità di aggiungere comportamenti senza modificare il framework che deve essere arricchito, queste sono le caratteristiche principali di AOP.

AspectJ

Lo strumento di cui parleremo in questo articolo è AspectJ, un compilatore gratuito, che si appoggia a javac e permette di integrare, all’interno delle proprie classi, degli aspect.Questo compilatore è facilmente scaricabile da: http://www.eclipse.org/aspectj/, e si installa con la clas-sica invocazione da riga comando: java -jar aspectj-1.5.0.jar.Una volta installato, viene creata una cartella su disco, generalmente c:\aspectj1.5\, che conterrà sia il compilatore che le librerie per poterlo utilizzare.Il passo successivo sarà quello di mettere in path la directory c:\aspectj1.5\bin e in classpath il jar di As-pectJ: c:\aspectj1.5\lib\aspectjrt.jar.

Dopo anni di programmazione strutturata, si è passati ad anni di programmazione ad oggetti. Ora si inizia a parlare di POP (Post Object Programming), e delle tecnologie correlate. AOP (Aspect Oriented Programming), è appunto una di queste tecnologie. Vediamo di cosa si tratta, con esempi pratici e l’utilizzo di un compilatore gratuito come AspectJ.

>> di Matteo Baccan (matteo.baccan@javajournal.it)

JAVA Journal

n.3 - marzo/aprile 2007 55

focus

Fatte queste due operazioni basilari, siamo pronti per uti-lizzare AspectJ e creare le prime applicazioni AOP. Inizia-mo quindi ad introdurre alcuni concetti di base.

Concetti di base

Alla base della programmazione AOP c’è il concetto di cros-scutting concern (CC), traducibile in interesse trasversale.Quando si parla di CC, si fa riferimento ad un requisito che può essere pensato in modo autonomo, ed applicato in più punti, all’interno del progetto che si sta sviluppando, senza essere necessariamente legato alla funzionalità che si intende sviluppare.Il poter astrarre un requisito, per poi applicarlo in modo orizzontale, ci permette di racchiudere la problematica in quello che viene definito aspect. All’interno di un aspect, sono poi presenti le regole che indicano dove applicarlo.Il vantaggio di un aspect è appunto il fatto di essere rac-chiuso all’interno di un proprio sorgente, dove non vi è di-pendenza diretta rispetto alle classi dove verrà applicato.Per questo motivo, è possibile uno sviluppo parallelo di requi-siti. Sarà poi compito del compilatore, nel nostro caso AspectJ, fondere regole e classi, all’interno dello stesso framework. Pro-viamo ora ad approfondire questi concetti con degli esempi.

Log degli accessi

Ipotizziamo di dover controlla-re tutti gli accessi ad una certa classe. Le ragioni potrebbero essere svariate: un controllo di utilizzo, un test di performance o l’applicazione di un controllo di accesso.L’idea è quella di creare un as-pect, in grado di intercettare tutti gli accessi ad un certo metodo di una certa classe, visualizzandoli a video.

Chiaramente, la partenza di tutto è un framework preventivamente costituito, sul quale vogliamo aggiungere il controllo d’accesso.Perché non modificare direttamente il fra-mework? Le ragioni potrebbero essere molteplici, come il non disporre dei sorgenti del framework, oppure il dover applicare tali modifiche solo ad un progetto che lo utilizza, ma non a tutte le applicazioni che lo utilizzano, evitando quindi di aggiungere codice inutile dove non serve.Se vogliamo analizzare la problematica, dal pun-to di vista dell’Object Orientation (OO), il primo approccio che potrebbe venire in mente, in que-sto caso, è quello di creare una classe di controllo accessi, modificare il sorgente della classe che deve aggiungere la funzionalità, inserirvi un me-todo di controllo e modificare tutti i sottometodi che devono essere controllati, con la chiamata a questo metodo.Questo approccio obbliga, necessariamente, la modifica di gran parte del codice della classe,

rendendo, di fatto, il controllo d’accesso una funzionalità obbligatoria, in ogni ambito in cui la classe è utilizzata.In un’ottica di riutilizzo del framework, si traduce nel aver introdotto qualcosa che servirà solamente in un certo caso specifico, ma non nella totalità dei casi in cui verrà utilizzato il framework stesso. Ne consegue una struttura similare a quella presente in Figura 1.

Vediamo invece cosa cambia, nel momento in cui decides-simo di creare un aspect.Ciò che viene stravolto totalmente è il modo col quale applicare il controllo d’accesso. Non occorre più mo-dificare le classi o i framework che devono supportare questo nuovo requisito, ma basta creare singolarmente il requisito, all’interno di un aspect, definire quando deve essere applicato e compilarlo insieme al codice del framework. Questa modalità permette di aggiungere del codice, ad applicazioni già scritte, senza bisogno di modificarle. Le classi quindi, non devono ereditare da un qualcosa, ma è quel qualcosa che si inserisce nelle classi. Ne risulta, quindi, una struttura simile a quella mostrata nella Figura 2, dove non si parla più di ere-ditarietà della classe di controllo degli accessi, ma di utilizzo.

FIGURA 1 Struttura delle classi senza AOP

FIGURA 2 Struttura delle classi con AOP

JAVA Journal

n.3 - marzo/aprile 200756

focus

Elementi fondamentali della programmazione AOP

Chiarita la differenza di approccio rispetto alla program-mazione Object Oriented, vediamo di scendere maggior-mente in dettaglio, rispetto a AOP, introducendo un set minimale di costrutti, con i quali è possibile creare qual-siasi tipo di aspect e di conseguenza poter sfruttare appieno questo paradigma di programmazione.I costrutti che occorre conoscere sono:

• oin Point: è il punto di esecuzione di un programma: il richiamo di un metodo o l’assegnazione di una variabile d’istanza;

• Pointcut: è il meccanismo che permette di selezionare su quali Join Point andrà ad agire un Advice;

• Advice: è il codice che deve essere eseguito nel Join Point selezionato dal Pointcut;

• Aspect: è l’insieme di Advice e Pointcut.

In base a queste descrizioni, se volessimo definire cos’è un aspect potremmo dire: è una regola che indica il punto dove deve essere eseguito del codice. Il concetto di base è molto semplice, ma allo stesso modo molto potente. Vediamo ora di capire quali sono i Join Point sui quali possiamo agire:

• Method execution/call: durante l’esecuzione o il richia-mo di un metodo;

• Constructor execution/call: durante l’esecuzione o il ri-chiamo di un costruttore;

• Class initialization: all’atto dell’inizializzazione di una classe;

• Field read/write: alla scrittura o lettura in una variabile d’istanza;

• Exception handler: quando si verifica un’eccezione;• Object initialization/pre-initialization: all’atto dell’ini-

zializzazione di un oggetto;• Advice execution: all’ese-cuzione di un Advice.

Con queste direttive, si riescono a coprire tutte le casistiche di una normale struttura ad oggetti.Vediamo ora le caratteri-stiche che possono avere i singoli costrutti, per meglio comprendere come e quando applicarli

Applicazione di un Join Point

Come abbiamo spiegato nel paragrafo precedente, un Join Point, può essere applicato sia in fase di esecuzione, sia in fase di ri-chiamo di un certo metodo. La domanda più spontanea che può venire in mente è: perché questa differenza?

In effetti, aggiungere del codice in un solo punto, all’in-terno di un metodo, o aggiungerlo in ogni sua esecuzione, non cambia il risultato che si vuole ottenere. Cambia però a livello di risparmio di codice e cambia soprattutto se non si può modificare direttamente il sorgente della classe che intendiamo controllare.Partiamo da un caso reale: si vuole condizionare l’utilizzo di un certo metodo di una certa classe. Ipotizziamo che, tale metodo, sia all’interno di una classe di cui disponiamo il sorgente.In questo caso, il punto migliore per poter applicare l’aspect è nel momento dell’esecuzione, quindi dentro il metodo stesso. Se però il metodo non ci è stato dato in chiaro, per-ché contenuto in una classe di cui abbiamo solo la libreria (.jar), l’unico modo con cui possiamo applicare l’aspect è al momento del suo utilizzo.Sicuramente questo secondo modo di utilizzare un aspect è più prolisso, ma è l’unico modo col quale possiamo appli-carlo in questo contesto.

LISTATO 1

Classe Demopublic class Demo { public static void main(String[] args){ Demo d = new Demo(); d.go(); }

public Demo(){} public String cVar = “”; public void go(){ metodo1( “PAR1” ); System.out.println( “passo 100 a Metodo2 [“ +metodo2( 100 ) +”]” ); } public void metodo1( String cPar ){ System.out.println( “Metodo1 chiamato con parametro stringa [“ +cPar +”]”); } public String metodo2( int n ){ System.out.println( “Metodo2 chiamato con parametro numerico [“ +n +”]”); return “valore di ritorno*2 (“ +(n*2) +”)”; }}

Esistono delle

esigenze orizzontali

ad un framework, che

dovrebbero far parte di

tutte le classi

JAVA Journal

n.3 - marzo/aprile 2007 57

focus

Call / Execution

Proviamo quindi a creare un Aspect, partendo dalla classe Demo presente nel Listato 1:

La classe d’esempio dispone di due metodi. Il primo non restituisce alcun risultato, mentre il secondo, restituisce un risultato String. Quello che dobbiamo creare ora è un aspect, come illustrato di seguito:

Aspect

aspect Logging { pointcut primo_metodo(): call( void Demo.metodo1(String)); pointcut primo_metodo2(): execution( String Demo.metodo2(int)); void around(): primo_metodo() { System.out.println(“Prima”); proceed(); System.out.println(“Dopo”); } String around(): primo_metodo2() { System.out.println(„Prima2“); String cRet = proceed(); System.out.println(“Dopo2”); return cRet; }}

Un aspect è sintatticamente molto simile ad una classe, di cui ricorda molto la struttura.Le differenze sono minime, ma importanti.Al posto del token class, per indicare un aspect, occorre scri-vere “aspect”.Dopo la definizione del nome, possiamo passare a definire i pointcut e soprattutto i punti in cui devono agire: se al ri-chiamo, call, del metodo o se alla sua esecuzione, execution.Una volta decisa la modalità, possiamo indicare quale gruppo di metodi, o singolo metodo, deve essere impatta-to. Nel nostro caso si è deciso di indicare i due metodi della classe Demo.Ultimo punto da affrontare, è quello di creare un advice, nel quale inserire il codice da eseguire.Anche l’advice ha una propria sintassi, data dal ritorno del metodo da arricchire, dalla modalità di utilizzo, nel nostro caso around, cioè “attorno” al metodo che stiamo modifi-cando, e da un proprio nome.Una volta definito, possiamo creare tutto il codice Java che desideriamo, ricordandoci di utilizzare il metodo proceed() per attivare il metodo che si stava modificando.Per compilare queste righe con AspectJ è sufficiente chia-mare il compilatore ajc passando, tramite una @, il nome del file contenente l’elenco dei sorgenti da compilare, come in questo esempio: ajc @files.lst. A questo punto, invocando l’esecuzione della classe Demo (java demo), otterremo l’ouput:

Esecuzione

PrimaMetodo1 chiamato con parametro stringa [PAR1]DopoPrima2Metodo2 chiamato con parametro numerico [100]Dopo2passo 100 a Metodo2 [valore di ritorno*2 (200)]

L’effetto è quello di avere, prima e dopo l’esecuzione dei due metodi, la visualizzazione di due messaggi. Chiara-mente, se al posto dei messaggi ci fosse stato il controllo d’accesso, avremmo risolto in modo ottimale la problema-tica, senza impattare la classe Demo.

Staticinitialization

Altro punto interessante, nel quale applicare un aspect, è l’inizializzazione di un oggetto tramite un costrutto static.L’inizializzazione statica viene applicata tutte le volte in cui, in una classe, si ha l’esigenza di creare un qualcosa di comune a più istanze della classe stessa. Un esempio potrebbe essere la lettura di un file di configurazione, o la creazione dati statici.Tale inizializzazione avviene una sola volta sola, in tutto il programma. Potrebbe però essere interessante modificarne il comportamento o semplicemente notificarne l’esecuzio-ne.Anche in questo caso c’è un apposito pointcut da definire. Come si può notare nel prossimo listato, la cosa che cam-bia è la direttiva staticinitialization da passare al pointcut. Per quanto riguarda l’advice, la sintassi è la stessa del caso precedente. La cosa che varia è la presenza di void come valore di ritorno, dato che le inizializzazioni non hanno un valore di ritorno.

Staticinitialization

aspect Logging { pointcut primo_metodo() : staticinitialization( Demo );

L’idea è quella di

creare un aspect, in

grado di intercettare

tutti gli accessi ad un

certo metodo di una

certa classe

JAVA Journal

n.3 - marzo/aprile 200758

focus

void around() : primo_metodo() { proceed(); }}

Set/Get

Così come possiamo controllare l’accesso ad un metodo, è possibile controllare l’accesso ad una variabile d’istanza, sia in lettura che in scrittura. Per fare questo è possibile utilizzare un pointcut dove indicare quale variabile, di quale classe, andare a controllare. Per quanto riguarda l’advice, rimane tutto invariato, come nel caso del metodo:

Set/Get

aspect Logging { pointcut primo_metodo() : set( String Demo.cVal ); pointcut primo_metodo2() : get( String Demo.cVal ); void around() : primo_metodo() { proceed(); } String around() : primo_metodo2() { String c; c = proceed(); return c; }}

This/Target

Un’altra modalità di attivazione, specificabile all’interno di un pointcut è data dalla classe di attivazione.Ipotizziamo di avere più classi che hanno un metodo co-mune chiamato go. Invece di specificare N pointcut, uno per ogni metodo di ogni classe, possiamo indicarne uno solo, utilizzando la wildcard “*”. Un esempio potrebbe essere “pointcut pc(): execution( * *.go() )”: dato qualsiasi metodo go, di qualsiasi classe, con qualsiasi valore di ritorno, gesti-sci il pointcut pc().Chiaramente, tutto funziona correttamente, nel caso in cui ci siamo poche classi. Quando invece si utilizzano fra-mework molto grandi, potrebbe essere necessario limitare la capacità di questo pointcut. Per questo sono stati intro-dotte le estensioni this( classe ) e target( classe ).Tramite questi due costrutti è possibile limitare un pointcut all’interno di una certa classe (this) o solamente quando viene chiamato in una certa classe (target), come esposto in seguito:

This/Target

aspect Logging { pointcut primo_metodo(): execution( * *.go() ) && this(Demo2); void around(): primo_metodo() { proceed(); }

pointcut primo_metodo2() : execution( * *.go() ) && target(Demo); void around(): primo_metodo2() { proceed(); }}

Args

Altro filtraggio possibile sui pointcut è dato dai parametri passati. È infatti possibile utilizzare delle wildcard e paral-lelamente indicare che, i parametri gestiti dal metodo che si intende controllare, sono di un certo tipo. In seguito è presente un esempio di utilizzo di args() collegato a tutti i metodi che ricevono come argomento un oggetto String.

Args

aspect Logging { pointcut primo_metodo() : execution( void *.*(*) ) && args( String );

void around() : primo_metodo() { System.out.println(“Prima”);

Questa modalità

permette di aggiungere

del codice, ad

applicazioni già scritte,

senza bisogno di

modificarle

JAVA Journal

n.3 - marzo/aprile 2007 59

focus

proceed(); System.out.println(“Dopo”); }}

Advice

Ora che abbiamo ben compreso come creare dei poin-tcut, vediamo quali tipo di esecuzione è possibile far fare ad un advice.Oltre ad around, osservato negli esempi precedenti, è possibile anche indicare before se vogliamo eseguire del codice prima del pointcut, o after, se lo vogliamo esegui-re dopo.Da notare che un advice è di per se molto simile ad un metodo, in quanto, come un metodo:

• Segue delle regole di accesso per essere eseguito• Può generare un’eccezione• Può fare riferimento all’aspect corrente tramite this

Al contrario di un metodo però:

• Non ha un nome• Non può essere chiamato direttamente, è il sistema

che lo esegue• Ha accesso ad alcune variabili valorizzate all’interno

di this che possono servire a prendere informazioni sui join point catturati: thisJoinPoint

Altro aspetto interessante degli advice è quello di poter essere eseguiti dopo il ritorno di un valore da un meto-do, oppure nel momento di un’eccezione nel codice.

Advice su eccezione

Ultimi, ma non meno importanti, sono gli Advice su eccezione. Chiaramente, anche in questo caso, esiste una sintassi ben precisa, che ricalca molto quella vista per i metodi.Si tratta di definire sempre il momento in cui inter-cettare l’eccezione (ex: after), indicare che si vogliono gestire le eccezioni: throwing e definire su quali metodi si intende farlo, nel caso del listato seguente sono stati indicati tutti i metodi: “* *.*()”.

Advice su eccezione

aspect Logging { after() throwing: call(* *.*()) { System.out.println(“ERRORE”); }}

Conclusioni

Questo articolo è un’introduzione alla programmazio-ne AOP. Non sono stati toccati i concetti più complessi

di questo tipo di programmazione, ma solo i concetti base, che permettono di capire come iniziare a pro-grammare. Come si può notare, il concetto base di AOP è molto semplice. Servono poche righe di codice per arricchire in modo concreto, molte classi di nuove funzionalità.Piuttosto, il problema di AOP è la sua giovane età. Il supporto per questo tipo di programmazione non è an-cora molto diffuso, anche se inizia a essere presente in alcuni ambienti di sviluppo.Inoltre, pensare in AOP, richiede un ulteriore passo in avanti, rispetto alla programmazione Object Oriented, passo di cui non si sente ancora l’esigenza diffusa. Come tutte le cose, il tempo ci potrà dare ragione o potrà cancellare completamente questo approccio post-object oriented.

Bibliografia

[1] http://www.eclipse.org/aspectj/, AspectJ[2] http://www.eclipse.org, il progetto Eclipse[3] http://www.eclipse.org/aspectj/downloads.php, la pagina di download di AspectJ[4] http://www.baccan.it/index.php?sezione=webbit2004, dove poter scaricare i sorgenti d’esempio analizza-ti in questo articolo.

Un aspect è una regola

che indica il punto dove

deve essere eseguito

del codice

Note Biografiche

Matteo Baccan è uno specialista di progettazione e svilup-po C++, JAVA e AOP. È ideatore del portale JobCrawler.it e speaker in importanti eventi Java (Javaday, JIP Day). Attual-mente si occupa di analisi presso un importante operatore di telefonia mobile. Può essere contattato tramite il suo sito http://www.baccan.it.