mercoledì, marzo 28, 2007

Hookka che ti hookko anch'io

Confronto fra tecniche di hooking e l'AOP

Piccola osservazione forse banale:
  • le tecniche di hooking consentono di definire dei punti del proprio codice in cui l'esecuzione di codice esterno è ammessa previa registrazione di simpatiche funzioncine di callback, questo ad esempio permette a mtrace di tracciare l'attività della libreria malloc (ad es. funzioni malloc, realloc, free, ...). Ogni funzione di callback è però registrata come callback per esattamente una funzione da tracciare, eventualmente tipizzata per poter tracciare punti differenti;
  • l'AOP (Aspect Oriented Programming) prevede la possibilità di dichiarare degli aspetti come collezioni di azioni da poter eseguire eventualmente dietro esplicita richiesta oppure prima o dopo l'esecuzione di ben precisi metodi degli oggetti di ben precise classi (o tutte, o una parte). Differenti aspetti possono definire differenti azioni o classi su cui operano o metodi che "modificano".
Ok, questo era un riassunto BRUTTISSIMO e non esattamente corretto di quello che sono le due tecniche.. ora le riflessioni:
  • esiste sempre del codice esterno (es. funzioni) da eseguire in determinati punti del codice delle classi che descrivono le entità del dominio;
  • esiste sempre una tipizzazione (tipo di hook, aspetto legato all'azione);
  • si tenta sempre di imporre una separazione fra il codice che si vuole "iniettare" ed il codice preesistente;
  • gli aspetti lavorano su sottoinsiemi di classi, l'hooking lavora su ogni singola funzione.
Non vi sembrano simili simili simili? Decisamente direi che è possibile mettere l'hooking e l'AOP sotto lo stesso tetto. In realtà le implementazioni dell'AOP in genere prevedono un preprocessore che modifichi il codice sorgente prima della compilazione mentre nell'hooking tutto è eseguito a run-time.. però questo è solo un dettaglio tecnico.
Esempio.. ho implementato uno strumento di hooking per Matlab (FHook) che consente di fare anche AOP, è grezzo, non consente di sfruttare il pattern-matching per la selezione delle funzioni/sottofunzioni a cui applicare gli aspetti o su cui fare hooking.. però anche come strumento embrionale direi che può essere utile e si può usare per studiare a fondo questa simbiosi di concetti ;)

6 commenti:

Sonia79 ha detto...

Magari dico una cavolata, ma le tecniche di hooking non si possono vedere come un sottoinsieme della AOP? Nel senso, l'aggiunta di chiamate a codice esterno possono essere interpretate come un particolare 'aspetto' della AOP.

Mumble mumble

Gabriele Lombardi ha detto...

Mmm.. non credo di aver capito esattamente.. però pensandoci ho capito una cosa: tra tutte queste simpatiche tecniche di SE (Software Engeneering) e tutti sti simpatici paradigmi di programmazione c'è un'intersezione decisamente non vuota!
Esempio: nella discussione di questo post, e nel SW Matlab, ho mostrato come costruire uno strumento di hooking utilizzando un linguaggio di scripting procedurale, e poi ho fatto vedere come usare questo per ottenere l'AOP.. ma la mia domanda a sto punto è: l'hooking è un paradigma o una tecnica di SE? E l'AOP è veramente un paradigma o è solo una tecnica di SE applicata all'OOP?

Risposta idiota: e se il paradigma procedurale fosse l'unico paradigma, e tutto il resto fossero tecniche di SE? Del resto ci sono libri e articoli che mostrano come ottenere in C l'OOP.. partendo sempre dal procedurale quindi!

Commento.. E CHE CASINO ;)

Sonia79 ha detto...

Secondo me stiamo solo facendo della filosofia informatica... dettagli insomma; va bene suddividere i concetti ma secondo me queste differenze sono davvero sottili... forse troppo...

:)

Sonia

nataluca ha detto...

AOP = Hooking "automatizzato" ;-)

In pratica è injection dichiarativa ossia "dichiaro" i punti di innesto e cosa verrà innestato ma non mi preoccupo di farlo io... infatti qualcun altro mi ha sfornato il tool ;-)


"Caesar mutande mutandis..." De Bello Gallico

Gabriele Lombardi ha detto...

Ok, allora, pensandoci ho capito che banalmente, programmando in qualunque linguaggio di programmazione, in qualunque ambiente e qualunque paradigma, siccome si lavora sostanzialmente su una macchina a stack, alla fine dei conti si genera codice procedurale.

Quindi IL PARADIGMA DI BASE E' SEPRE PROCEDURALE.

A questo punto il sottile filo che regge le differenze fra paradigmi e tecniche di SE è da ricercare nell'architecture hiding offerto dai linguaggi di programmazione: ovvero dalla capacità che hanno i linguaggi di programmazione di mostrare nativamente gli strumenti di uno piuttosto che un'altro paradigma nascondendo la base procedurale.

Il SE si differenzia perchè usa un paradigma per costruire strumenti propri di un'altro senza nasconderne i dettagli? Ai miei lettori l'ardua sentenza ;)

nataluca ha detto...

Concordo con la tua opinione... alla fine il paradigma è sempre procedurale... SE... effettivamente mostra la natura vera dei linguaggi esponendole in un altro modo... mm... affascinante ma intricato...