Quel est un bon exemple de cross-cutting concern? L'exemple de dossier médical sur la page wikipedia me semble incomplet.
Particulièrement à partir de cet exemple, pourquoi la journalisation conduirait-elle à une duplication de code ( dispersion )? (Outre les appels simples comme log("....")partout, ce qui ne semble pas être un gros problème).
Quelle est la différence entre a core concernet a cross-cutting concern?
Mon objectif final est de mieux comprendre l'AOP.
Réponses:
Avant de comprendre la préoccupation transversale , nous devons comprendre la préoccupation .
Une préoccupation est un terme qui fait référence à une partie du système divisée en fonction de la fonctionnalité.
Les préoccupations sont de deux types:
Cette figure représente une application typique décomposée en modules. La principale préoccupation de chaque module est de fournir des services pour son domaine particulier. Cependant, chacun de ces modules nécessite également des fonctionnalités auxiliaires similaires, telles que la journalisation de la sécurité et la gestion des transactions. Un exemple de problèmes transversaux est la «journalisation», qui est fréquemment utilisée dans les applications distribuées pour faciliter le débogage en traçant les appels de méthode. Supposons que nous enregistrions au début et à la fin de chaque corps de fonction. Cela entraînera le croisement de toutes les classes qui ont au moins une fonction.
Je pense que le meilleur exemple d'une préoccupation transversale est le comportement transactionnel. Devoir mettre des blocs try-catch avec des appels de validation et d'annulation dans toutes vos méthodes de service serait répulsif, par exemple. Annoter les méthodes avec un marqueur que AOP peut utiliser pour les encapsuler avec le comportement transactionnel souhaité est une grande victoire.
L'autorisation est un autre bon candidat comme exemple de préoccupation transversale. Il peut être préférable d'annoter une méthode de service avec un marqueur qui indique qui peut l'appeler et de laisser certains conseils AOP décider d'autoriser ou non l'appel de méthode plutôt que de gérer cela dans le code de méthode de service.
La mise en œuvre de la journalisation avec les conseils AOP pourrait être un moyen d'obtenir plus de flexibilité, de sorte que vous puissiez modifier ce qui est journalisé en modifiant un point de jointure. En pratique, je ne vois pas de projets faire cela très souvent. En général, l'utilisation d'une bibliothèque comme log4j qui vous permet de filtrer par niveau de journalisation et par catégorie, au moment de l'exécution si vous en avez besoin, fonctionne assez bien.
L'une des principales préoccupations est la raison pour laquelle l'application existe, la logique métier que l'application automatise. Si vous avez une application logistique qui gère le fret d'expédition, déterminer la quantité de cargaison que vous pouvez emballer sur un camion ou quel est le meilleur itinéraire pour le camion pour déposer ses livraisons peut être une préoccupation majeure. Les préoccupations transversales sont généralement des détails de mise en œuvre qui doivent être séparés de la logique métier.
En plus de la réponse acceptée, je veux citer un autre exemple de préoccupation transversale: la communication à distance. Disons que je veux juste appeler d'autres composants de mon écosystème localement comme s'ils s'exécutaient en cours. Peut-être que dans certains cas, ils le font même. Mais maintenant, je souhaite exécuter mes services distribués dans un cloud ou un cluster. Pourquoi devrais-je me soucier de cet aspect en tant que développeur d'applications? Un aspect pourrait prendre soin de savoir qui appeler et et comment, sérialiser les données transmises si nécessaire et effectuer un appel à distance. Si tout fonctionnait en cours, l'aspect ne ferait que transférer l'appel local. Du côté de l'appelé, l'aspect désérialise les données, effectue l'appel local et renvoie le résultat.
Maintenant, laissez-moi vous raconter une petite histoire à propos de choses "triviales" comme la sortie de journal: il y a quelques semaines à peine, j'ai refactoré une base de code complexe, mais pas trop grande (environ 250K lignes de code) pour un client. Dans quelques centaines de classes, un type de cadre de journalisation a été utilisé, dans quelques centaines un autre. Puis il y avait plusieurs milliers de lignes deSystem.out.println(*)où il aurait vraiment dû y avoir une sortie de journal. J'ai donc fini par corriger des milliers de lignes de code dispersées dans la base de code. Heureusement, je pourrais utiliser quelques astuces intelligentes dans IntelliJ IDEA (recherche et remplacement structurels) afin d'accélérer toute l'action, mais ne pensez-vous pas que c'était trivial! Bien sûr, la journalisation du débogage fortement dépendante du contexte se produira toujours dans le corps d'une méthode, mais de nombreux types importants de journalisation tels que le suivi des appels de méthode (même hiérarchiquement avec une sortie bien indentée), la journalisation des exceptions gérées ou non gérées, l'audit utilisateur (journalisation des appels à méthodes restreintes basées sur les rôles des utilisateurs) et ainsi de suite peuvent être facilement implémentés dans certains aspects sans qu'ils polluent le code source. Le développeur d'applications de tous les jours n'a pas besoin d'y penser ni même de voir les appels de l'enregistreur dispersés dans la base de code.
Je peux trouver des explications similaires pour d’autres préoccupations transversales. Garder le code propre et exempt de dispersion et d'emmêlement IMO est une question de professionnalisme et non rien d'option. Last but not least, il garde le code lisible, maintenable, refactorable. Amen.
Les préoccupations transversales sont les scénarios qui devraient toujours être présents quel que soit le type d'application.
Par exemple, la journalisation, la sécurité, le profilage des performances, la localisation, l'accessibilité, la transaction, etc. La sécurité (authentification / autorisation, etc.) est nécessaire lorsque seul un utilisateur authentique peut entrer dans l'application avec le bon ensemble de privilèges. Nous avons besoin de savoir comment votre application fonctionne, puis nous devons faire le profilage. Dans le cas où l'application est utilisée par des utilisateurs internationaux (avec leur propre langue localisée), nous devons la prendre en charge dans l'application. L'accessibilité est des cas d'utilisabilité pour les personnes handicapées à utiliser notre application.
Maintenant, que notre application soit basée sur un ordinateur de bureau, sur le Web, etc., si elle doit être utilisée par les utilisateurs finaux à travers la géographie dans l'environnement de production, des coupes transversales sont nécessaires. Jusqu'à présent, je n'ai rien dit sur l'application, etc., mais compte tenu de la liste des problèmes à résoudre avant de la diffuser aux utilisateurs finaux dans l'environnement de production. et tout est question de problèmes croisés (qui doivent être gérés par toutes les applications / méthodes / classes, c'est-à-dire à différents niveaux).