Venendo in ritardo al gioco, ma fornisco questo per gli sviluppatori successivi che potrebbero imbattersi in questa domanda.
Vorrei strongmente sconsigliare AOP se l'applicazione dipende su di esso per funzionare correttamente. Gli aspetti funzionano così:
-
Consigli (comportamento aggiuntivo) viene applicato a
-
Punti di unione (luoghi in cui è possibile collegare il codice aggiuntivo, ovvero iniziare o terminare un metodo o quando si attiva un determinato evento)
- ... dove i pattern pointcut (un pattern che rileva se un dato punto di join corrisponde)
Per chiunque abbia fatto computer da molto tempo, il fatto che i pattern siano usati potrebbe essere qualcosa da guardare da vicino. Quindi, ecco un esempio di un collegamento che corrisponde a qualsiasi metodo denominato set indipendentemente dagli argomenti:
call(* set(..))
Quindi questo è un punto di discussione abbastanza ampio e dovrebbe essere chiaro che maneggiarlo con cura è consigliato (non è un gioco di parole) perché stai chiedendo consigli a molte cose.
O diamine, applichiamo i consigli a tutto , indipendentemente dal nome o dalla firma!
execution(* *(..))
Quindi dovremmo stare attenti perché qui c'è molto potere, ma questo non è un argomento contro gli aspetti - è un argomento di cautela perché qui c'è molto potere e la corrispondenza dei modelli può facilmente andare storto (basta premere il tuo preferito motore di ricerca per cimici e divertiti).
Quindi ecco quello che sembra un pointcut relativamente sicuro:
pointcut setter(): target(Point) &&
( call(void setX(int)) ||
call(void setY(int)) );
Che fornisce esplicitamente un consiglio se vengono trovati metodi denominati setX o setY su un oggetto Point . I metodi possono ricevere solo int s e devono essere void . Sembra abbastanza sicuro, giusto? Bene, questo è sicuro se quei metodi esistono e hai applicato il consiglio corretto. Se no, peccato; fallisce silenziosamente.
Per fare un esempio, un amico stava provando a eseguire il debug di un'applicazione Java in cui tutti, una volta ogni tanto, avrebbero restituito dati non corretti. Si è trattato di un errore raro e non sembra essere correlato a particolari eventi o dati in particolare. Era un bug di threading, qualcosa che è notoriamente difficile da testare o rilevare. A quanto pare, stavano usando aspetti per bloccare i metodi e renderli "thread safe", ma un programmatore ha rinominato un metodo e un pointcut non è riuscito a farlo corrispondere, causando così una rottura silenziosa dell'applicazione.
Quindi, dico alle persone che se devono utilizzare AOP, per trattare aspetti come le eccezioni: in un sistema ben progettato e se nulla va storto, possono essere rimossi e il software funziona ancora correttamente . Tuttavia, se la funzionalità del programma dipende da AOP, si introduce una fragilità nel programma che non è giustificata.
Quindi, logging, debugging e tracing sono ottimi esempi di comportamenti perfetti per gli aspetti, ma sicurezza? No. Filo di sicurezza? No..
Per una valida alternativa all'AOP, vedi tratti . Piuttosto che essere imbullonati al linguaggio, sono integrati direttamente in esso, non hanno bisogno di un IDE "tratto consapevole" (sebbene possa essere d'aiuto) e hanno fallimenti in fase di compilazione se i metodi richiesti non sono presenti. I tratti svolgono un lavoro molto più accurato nel gestire la separazione delle preoccupazioni perché il problema è stato definito meglio sin dall'inizio. Li uso estensivamente e sono fantastici.