La programmation orientée aspect est-elle utile pour fournir des implémentations pour la programmation par interface?

Question

J'étais simplement curieux à propos du sujet. Je n'ai jamais utilisé de programmation orientée aspect (intentionnellement), et je n'ai que peu de connaissances à ce sujet.

Voici ma question (en utilisant l'exploitation forestière comme cas d'utilisation typique):

Si j'ai un paradigme basé sur l'interface existante par exemple considérer le pseudo-code

class MyClass implements Loggable { 

    // Logable Implementation 
    string Log() { return somelogstring;} 
} 

programmation orientée aspect peut être utilisé avec cela d'une manière comme

class MyClass implements Loggable with LoggingAspect { 

    // No explicit Loggable implemenation 
} 

Est-ce quelque chose qui serait considéré comme AOP? Si oui, est-ce une façon valide de l'utiliser?

Answer 1

AOP a été créé pour mettre en œuvre les préoccupations qui transcendent (comme l'exploitation forestière), les préoccupations que « coupes » entre les différents modules sur votre application. Si vous implémentez l'enregistrement avec AspectJ, par exemple, vous aurez un aspect comme celui-ci:

public aspect Logging(){ 

    pointcut traceMethods() : (execution(* *.*(..)) && !within(Logging); 

    before(): traceMethods() { 
     // Perform log here! 
    } 

} 

Ce code mettra en œuvre la fonctionnalité de journal avant l'exécution de toutes les classes de votre application. Donc, il va insérer le comportement de la connexion sur certains classements que vous voulez. Pour indiquer quelles classes seraient affectées par la journalisation, vous devez définir un pointcut (ou un ensemble de pointcus). Dans cet exemple, le pointcut est le traceMethods().

Réflexion sur les interfaces que vous devriez regarder this link that explains Inter-type declarations.Ces déclarations pourraient être utilisées pour «implémenter» quelque chose comme des interfaces en utilisant AspectJ.

Answer 2

De quelle langue parlez-vous ici?

Et non, ce n'est pas comment AOP se fait généralement, et sans doute pas possible dans les langues avec de tels cadres (C#, .NET). Ce dont vous parlez ici est une phase de pré-construction, c'est-à-dire que vous avez du code qui ne compile pas maintenant, et vous devez le compiler avant de l'envoyer au compilateur actuel ... AKA comme génération de code . la génération de code est une bonne chose à faire, et il existe des cadres pour cela dans différentes langues (encore une fois, dites-nous quelle langue).

Mais est-ce un AOP? AOP consiste à injecter des fonctionnalités dans des méthodes déjà existantes. C'est à dire. "hooker" des fonctions/actions, etc.

Answer 3

AOP consiste typiquement à appliquer une préoccupation transversale à travers une procédure sans affecter la mise en œuvre de ces procédures. Audit Logging est un bon exemple. Vous pouvez définir un aspect indiquant que "toutes les opérations affectant les comptes clients doivent être enregistrées". Vous pouvez implémenter cela procédurally dans toutes les opérations qui fonctionnent avec le compte, ou vous pouvez tirer ce code sur le côté.

Ceci est généralement mis en œuvre en insérant un comportement autour du code existant. Dans OO, de tels aspects peuvent être appliqués au moyen du modèle de proxy. La plupart des frameworks C# et Java AOP génèreront une classe proxy au moment de l'exécution en fonction des métadonnées de la classe cible et provoqueront l'exécution de certains codes avant et après les méthodes spécifiées.

Un grand nombre de conteneurs IoC fournir une fonctionnalité permettant de fixer ces aspects, ainsi que les concepts de aspects, l'interception de procédé, et l'injection de dépendance sont plus difficiles à distinguer que par le passé.

Answer 4

Non, ce n'est pas vraiment ce à quoi sert l'AOP. AOP ne sert pas à implémenter des interfaces au moment de l'exécution, mais pour systèmes de composition: la logique métier peut être définie à un endroit par exemple et la logique de journalisation dans un autre et un framework AOP les composera ensuite dans un système plus grand. L'AOP est conçu pour couvrir ce qu'il appelle des préoccupations transversales, c'est-à-dire la fonctionnalité requise par de nombreux objets dans un système mais qui n'est pas au cœur des préoccupations de ces objets. AOP fonctionne en interceptant les appels aux méthodes sur les objets et en effectuant certaines actions en plus ou à la place des actions effectuées par la méthode interceptée. Les points d'interception sont connus sous le nom de pointcuts et la méthode interceptée est la méthode conseillée, le code étant conseillé sur la méthode interceptée étant connu sous le nom de conseil.

Je ne connais que l'AOP via l'AOP Framework de Spring.Net qui vous permet de spécifier et d'appliquer des pointcuts et des conseils via des fichiers de configuration et par programmation. Spring.Net AOP a quatre types de conseils: before, after, around et throws qui sont invoqués lors de l'interception d'une méthode conseillée avant que la méthode conseillée soit invoquée, après qu'elle soit appelée, avant et après son invocation et lorsqu'une exception est levée respectivement. Qu'elle soit appliquée via la configuration ou par programmation, la méthode conseillée n'a aucune connaissance de Spring.Net AOP ou même qu'elle a été conseillée. La méthode conseillée doit cependant avoir une implémentation à intercepter afin que votre exemple ne fonctionne pas.

La documentation Spring.Net est très lisible et explique très bien l'AOP en général et l'implémentation Spring.Net de l'AOP en particulier et contient de nombreux exemples. Cela vaut la peine de regarder même si c'est juste pour mieux comprendre l'AOP.