J'arrive tard dans le jeu, mais je fournis cela aux développeurs ultérieurs qui pourraient tomber sur cette question.
Je déconseille fortement AOP si votre application en dépend pour fonctionner correctement. Les aspects fonctionnent comme ceci:
- Des conseils (comportement supplémentaire) sont appliqués à
- Points de jonction (endroits où le code supplémentaire peut être attaché, une telle méthode commence ou se termine, ou lorsqu'un événement donné se déclenche)
- ... où pointcut (un motif qui détecte si un point de jointure donné correspond) les motifs correspondent
Pour quiconque fait des ordinateurs depuis longtemps, le fait que des modèles soient utilisés pourrait être quelque chose à regarder de près. Voici donc un exemple de pointcut qui correspond à n'importe quelle méthode nommée set
quels que soient les arguments:
call(* set(..))
C'est donc un point de vue assez large et il devrait être clair que la manipulation avec soin est conseillée (sans jeu de mots) parce que vous appliquez des conseils à beaucoup de choses.
Ou diable, appliquons des conseils à tout , quel que soit le nom ou la signature!
execution(* *(..))
Donc, clairement, nous devons être prudents car il y a beaucoup de puissance ici, mais ce n'est pas un argument contre les aspects - c'est un argument pour la prudence car il y a beaucoup de puissance ici et la correspondance de modèles peut facilement aller de travers (il suffit de frapper votre moteur de recherche préféré pour aop bugs et amusez-vous).
Voici donc à quoi ressemble un pointcut relativement sûr:
pointcut setter(): target(Point) &&
( call(void setX(int)) ||
call(void setY(int)) );
Cela fournit explicitement des conseils si des méthodes nommées setX
ou setY
sur un Point
objet sont trouvées. Les méthodes ne peuvent recevoir que des int
s et elles doivent l'être void
. Semble assez sûr, non? Eh bien, c'est sûr si ces méthodes existent et que vous avez appliqué les bons conseils. Sinon, tant pis; il échoue silencieusement.
Pour donner un exemple, un ami essayait de déboguer une application Java où tout le monde de temps en temps, cela retournerait des données incorrectes. C'était un échec peu fréquent et ne semblait pas être en corrélation avec un événement particulier ou des données en particulier. C'était un bug de threading, quelque chose qui est notoirement difficile à tester ou à détecter. Il s'est avéré qu'ils utilisaient des aspects pour verrouiller les méthodes et les rendre "thread-safe", mais un programmeur a renommé une méthode et un pointcut n'a pas réussi à la faire correspondre, provoquant ainsi une interruption silencieuse de l'application.
Ainsi, je dis aux gens que s'ils doivent utiliser AOP, pour traiter des aspects comme les exceptions: dans un système bien conçu et si rien ne va mal, ils peuvent être supprimés et le logiciel fonctionne toujours correctement. Cependant, si la fonctionnalité du programme dépend d'AOP, vous introduisez une fragilité injustifiée dans votre programme.
Ainsi, la journalisation, le débogage et le traçage sont d'excellents exemples de comportements qui sont parfaits pour les aspects, mais la sécurité? Nan. Sécurité des fils? Nan.
Pour une alternative robuste à l'AOP, voir traits . Plutôt que d'être boulonnés sur le langage, ils y sont directement intégrés, n'ont pas besoin d'un IDE "sensible aux traits" (bien que cela puisse aider) et ont des échecs de compilation si les méthodes dont vous avez besoin ne sont pas présentes. Les traits font un travail beaucoup plus propre de gérer la séparation des préoccupations parce que le problème a été mieux défini dès le départ. Je les utilise beaucoup et ils sont fantastiques.