Arrivo in ritardo al gioco, ma lo fornisco agli sviluppatori successivi che potrebbero imbattersi in questa domanda.
Consiglio vivamente contro AOP se la sua applicazione dipende da essa per funzionare correttamente. Gli aspetti funzionano così:
- Viene applicato un consiglio (comportamento aggiuntivo)
- Unisci punti (luoghi in cui è possibile allegare il codice aggiuntivo, ad esempio l'inizio o la fine di un metodo o quando si attiva un determinato evento)
- ... dove corrispondono i pattern pointcut (un pattern che rileva se un dato punto di join corrisponde)
Per chiunque stia facendo computer da molto tempo, il fatto che i modelli vengano utilizzati potrebbe essere qualcosa da guardare da vicino. Quindi, ecco un esempio di un punto di corrispondenza che corrisponde a qualsiasi metodo denominato setindipendentemente dagli argomenti:
call(* set(..))
Quindi questo è un punto abbastanza ampio e dovrebbe essere chiaro che si consiglia di maneggiarlo con cura (non è previsto un gioco di parole) perché stai applicando consigli a molte cose.
O diamine, applichiamo consigli a tutto , indipendentemente dal nome o dalla firma!
execution(* *(..))
Quindi chiaramente dovremmo stare attenti perché c'è molto potere qui, ma questo non è un argomento contro gli aspetti - è un argomento di cautela perché c'è molto potere qui e la corrispondenza dei modelli può facilmente andare storta (basta colpire il tuo motore di ricerca preferito per aop bugs e buon divertimento).
Quindi ecco quello che sembra un punto relativamente sicuro:
pointcut setter(): target(Point) &&
( call(void setX(int)) ||
call(void setY(int)) );
Ciò fornisce esplicitamente consigli se vengono trovati metodi denominati setXo setYsu un Pointoggetto. I metodi possono solo ricevere intse devono essere void. Sembra abbastanza sicuro, giusto? Bene, è sicuro se esistono questi metodi e hai applicato il consiglio corretto. Altrimenti, peccato; fallisce silenziosamente.
Per fare un esempio, un amico stava cercando di eseguire il debug di un'applicazione Java in cui tutti di tanto in tanto restituivano dati errati. Si è trattato di un fallimento raro e non sembrava essere correlato a eventi o dati particolari 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 ribattezzato un metodo e un taglio di punti non è riuscito a combaciarlo, causando così un'interruzione silenziosa dell'applicazione.
Pertanto, dico alla gente che se devono usare 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 nel programma una fragilità ingiustificata.
Pertanto, la registrazione, il debug e la traccia sono ottimi esempi di comportamenti che sono perfetti per gli aspetti, ma la sicurezza? No. Sicurezza del filo? No.
Per una valida alternativa a AOP, vedi tratti . Invece di essere collegati al linguaggio, sono integrati direttamente in esso, non hanno bisogno di un IDE "consapevole del tratto" (anche se può aiutare) e hanno errori in fase di compilazione se i metodi richiesti non sono presenti. I tratti svolgono un lavoro molto più pulito nel gestire la separazione delle preoccupazioni perché il problema è stato meglio definito dall'inizio. Li uso ampiamente e sono fantastici.