Quelles sont les différences entre une programmation orientée aspect, orientée sujet et orientée rôle?

Je sais qu'il existe de nombreux articles décrivant ces trois paradigmes mais je cherche une explication schématique.

Il y a quelques très bonnes descriptions de programmation orientée aspect ici, donc je pose cette question dans l'espoir d'obtenir le genre de réponse de haute qualité que les gens de Stack Overflow sont habitués à fournir.

On peut y répondre en écrivant un livre à ce sujet. Cependant, voici une comparaison de base

1. Programmation orientée sujet

La programmation orientée sujet s'écarte radicalement de l'orientation orientée objet comme suit. En OO, les objets sont définis en termes intrinsèques (c'est-à-dire basés sur un modèle qui le décrit indépendamment). et sur cette base, ses attributs (propriétés) et méthodes (comportement) sont dérivés. L'application ne fait que l' utilisationde ces propriétés et comportements. Contrairement à cela, en programmation orientée sujet, aucun objet n'existe (et modélisé) dans un tel isolement. Dans le processus, mais les comportements des objets sont fournis par les divers autres "sujets" des objets qui sont hors de la portée et du contrôle de l'auteur de l'objet d'origine. Considérez-le comme un moyen d'étendre divers "comportements définissables indépendamment". "sur l'objet. Je pense que ce serait bien au-delà de la définition de modèles d'héritage par rapport à ce qui est discuté ici.

L'origine incontestée des termes (et du concept) provient de l'article " Programmation orientée sujet: une critique des objets purs , William Harrison et Harold Ossher". Voici un autre bon article . Bien que personnellement, je pense que c'est un cadre théorique. Je ne sais pas s'il y a des langues / implémentations

Voir ceci , ceci et cela pour plus d'informations.

2. Programmation orientée vers l'aspect

La programmation orientée vers l'aspect est née du concept de " séparation des oncernes ". Fondamentalement, il étend la programmation, soit procédurale, soit orientée objet, pour les préoccupations transversales. Trop simplifier, on peut dire que le logiciel a des exigences fonctionnelles et non fonctionnelles . Ces exigences transversales incluent des exemples tels que la journalisation, la gestion des exceptions, la synchronisation des threads, la gestion de la mémoire, l'optimisation, etc. Ces ASPECTS transversaux doivent être exprimés et mis en œuvre séparément et indépendamment à toute autre partie fonctionnelle.
Un travail complet dans ce domaine vient d' IBM ; essentiellement chacune de ces préoccupations oules aspects peuvent être indépendants les uns des autres formant un "espace de préoccupation" multidimensionnel. , (lire ceci ).

Certaines des bonnes implémentations pratiques d'Aspect Oriented sont AspectJ et AspectC ++ et bien d' autres . Regardez ça .

3. Programmation orientée vers les rôles
Au fur et à mesure que nous évoluons vers les agents, il est souvent nécessaire de définir des "rôles" et des objectifs où, en tant qu'activités précises, l'agent finit par dépendre de l'environnement dans lequel il se trouve. Ceci est analogue à la compréhension conceptuelle humaine.

L'objectif principal est de dissocier l'objectif de la tâche de sa capacité de coopération en définissant une construction explicite appelée processus de coopération . Un rôle est modélisé comme un ensemble de capacités et un comportement attendu. cependant, ces approches permettent également de modéliser l'environnement d'exécution et la façon dont l'agent / objet peut également percevoir l'environnement. Regardez ça .

Il existe différents cadres proposés dans la recherche pour la modélisation et les implémentations basées sur les rôles. Certains d'entre eux sont CORDE , BRAIN , Alaaddin et plus .