Quelles alternatives existe-t-il pour les préoccupations transversales autres que la programmation orientée aspect? [fermé]

La programmation orientée aspect promet de répondre aux préoccupations transversales, mais je ne suis pas encore complètement convaincu. Y a-t-il eu d'autres tentatives pour résoudre ce problème?

Lorsque cela est possible, vous pouvez encapsuler les préoccupations transversales dans des modules distincts qui sont ensuite utilisés dans l'application via l'injection de dépendances. Cela vous permet de découpler quelque peu l'implémentation des préoccupations transversales de son utilisation dans tout le code.

Cependant, cela ne fonctionne pas toujours avec élégance. C'est la raison pour laquelle les gens essaient de résoudre le problème avec des choses comme l'AOP.

Deux autres options que je n'ai pas encore vues explorées:

Programmation fonctionnelle avec des monades et des flèches

Dans FP, vous représentez une préoccupation transversale comme toute autre chose: comme quelque chose que vous transmettez lors d'un appel de fonction. Étant donné que cela devient explicitement fastidieux, vous pouvez utiliser des monades (ou peut-être des flèches) pour masquer les informations supplémentaires transmises.

L'exemple AOP le plus courant est la journalisation. Avec Monads, vous créez une monade "Logger" qui conserve une liste de messages. Toutes les fonctions que vous effectuez via LoggerMonad ont la possibilité de publier un message de journal. Avec Arrows, vous modéliseriez l'intégralité du flux de données de l'application et travailleriez une routine de journalisation dans le modèle, le cas échéant. Je pense. Les flèches sont assez complexes.

Programmation basée sur les entités / composants

Quelque chose que j'ai recherché et expérimenté pour un moteur de jeu. Au lieu d '"objets" comme dans la POO, vous décomposez tout en paquets de données (composants) et services qui fonctionnent sur un type de composant. Les composants sont regroupés par ID communs, comme dans une base de données relationnelle, et les groupes de composants liés sont les Entités. Pour ajouter la journalisation dans un tel système, vous devez ajouter un nouveau service de journalisation des déclencheurs en fonction des composants qui y sont passés.

Les deux méthodes permettent de travailler très facilement un changement transversal, mais les deux sont des modèles architecturaux de haut niveau. Vous devrez donc probablement les utiliser dès le début. Le modèle de composant peut, théoriquement, être intégré dans un système OOP existant. Je suppose que les monades pourraient l'être aussi si votre langue est suffisamment puissante.

Il existe plusieurs façons de résoudre les problèmes de préoccupations transversales:

• Utilisez de meilleurs modèles de conception, idiomes ou mécanismes d'abstraction : le code peut être transversal même s'il peut être modularisé. Afin de maintenir le code, vous devrez refactoriser pour utiliser la technique de conception qui peut le modulariser. Un tel refactoring peut introduire des coupes transversales d'un type différent, mais nous espérons que les coupes transversales sont stables et peu susceptibles de changer.

• Développer des fonctionnalités de langage plus riches : de nombreuses manifestations de transversalité peuvent être résolues grâce à de meilleurs mécanismes d'abstraction, et parfois de nouvelles fonctionnalités de langage sont nécessaires. Par exemple, les langages plus avancés qui incluent des fonctionnalités fonctionnelles et orientées objet n'emploient souvent pas autant de modèles de conception, car ils ne sont pas nécessaires. Notez que les modèles de conception eux-mêmes peuvent être de nature transversale , car ils décrivent les rôles de plusieurs objets et classes différents. En Java, la réflexion peut souvent être utilisée à la place d'un aspect, bien qu'à un coût d'exécution plus élevé. Par exemple, en utilisant la réflexion, vous pouvez prendre en charge le modèle de visiteur sur des centaines de classes avec seulement quelques lignes de code. La bibliothèque DJde Northeastern est une solution réfléchissante qui fait exactement cela. Les mixins sont une technique puissante disponible en C ++ (mais pas Java) et peuvent vous donner certains des mêmes cas d'utilisation qu'un aspect.

• Fournir une meilleure prise en charge des outils : des techniques telles que l'utilisation grepet l'exécution d'opérations de refactorisation peuvent traiter les problèmes liés au code transversal. Par exemple, le nom d'une méthode déclarée dans une interface peut traverser le programme. (Notez la différence technique ici: c'est le nom de la méthode, et non l'implémentation de la méthode, qui coupe.) Ce n'est généralement pas un problème dans un IDE comme Eclipse, où vous pouvez utiliser le "rename refactoring" pour changer tout les endroits de votre code qui utilisent le nom. De cette façon, il est possible de ne pas avoir besoin de fonctionnalités de langage lorsque l'environnement de programmation est suffisamment expressif pour vous.

• Utiliser des langages spécifiques au domaine : les premiers langages d'aspect, qui ont précédé AspectJ, étaient spécifiques au domaine et appliqués à certains problèmes seulement, tels que la synchronisation des threads ou l'analyse du flux de données pour combiner efficacement les compositions de fonctions. Ces langages étaient expérimentaux, mais semblaient très efficaces pour modulariser des préoccupations qui, autrement, étaient transversales.

• Utiliser des techniques de programmation générative : passer au niveau méta peut être considéré comme une technique de mise en œuvre pour la programmation orientée aspect, mais c'est un domaine suffisamment grand pour transcender les aspects simples. Les techniques génératives (où un programme génère du code source pour un autre programme) sont également liées aux langages spécifiques au domaine.

Pour tout cela, je pense que l'étude de l'AOP est appropriée. AOP peut vous aider à développer vos conceptions du code, même si vous n'utilisez pas de langage AOP.

En général, le balisage des éléments de code avec une fonction déclarative, mais en particulier le système d'attributs dans le monde C # /. NET / Mono.

Je ne suis pas un expert en AOP, mais à la lecture à ce sujet au fil des ans, il a toujours semblé être une forme plus faible de métaprogrammation offerte par Lisp , en particulier des parties comme son protocole de métaobjet.

Cela ne devrait pas surprendre, je suppose: Gregor Kiczales était l'un des auteurs d'AMOP, et a ensuite écrit AspectJ pour Java!