Is aspect oriented programming useful for providing implementations for interface based programming?

I was just curious about the subject. I have never used aspect oriented programming (intentionally), and I have only a small amount of knowledge about it.

Here's my question (using logging as the typical use-case):

If i have an existing interface based paradigm for example consider the pseudo-code

class MyClass implements Loggable {

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

Can aspect oriented programming be used along with this in a manne开发者_运维知识库r like

class MyClass implements Loggable with LoggingAspect {

  // No explicit Loggable implemenation
}

Is that something that would be considered AOP? If so, ss it a valid way to use it?

AOP was created to implement crosscutting concerns (like Logging), concerns that "cuts" between various modules on your application. If you implement the Logging with AspectJ, for example, you will have an aspect like this:

public aspect Logging(){

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

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

}

This code will implement the log functionality before the execution of all classes of your application. So, it will insert the behavior of logging on some classses that you want. To point what classes would be affected by the logging you should define a pointcut (or a set of pointcus). In this example, the pointcut is the traceMethods().

Thinking about interfaces you should look at this link that explains Inter-type declarations. This declarations could be used to 'implement' something like interfaces using AspectJ.

What language are you talking about here?

And no, this is not how AOP is generally done, and probably not possible in languages with such frameworks (C#, .NET).

What you're talking about here is a pre-build phase, i.e. you have code that doesn't compile now, and you need to make it compile before sending it to the actual compiler ... AKA as code generation. code generation is a fine thing to do, and there are frameworks for it in various languages (so again, tell us what language).

But is it AOP? No.

AOP is about injecting functionality into already-existing methods. I.e. "hooking" functions/actions, etc.

AOP is typically about applying a cross-cutting concern across a rance of procedures without affecting the implementation of those procedures. Audit Logging is a good example. You might define an aspect that says "all operations affecting customer accounts should be logged". You can implement this procedurally in all operations that work with the account, or you may wish to pull this code out to the side.

This is ususally implemented by inserting behavior around existing code. In OO, such aspects can be applied by means of the proxy pattern. Most C# and Java AOP frameworks will generate a proxy class at runtime based on metadata in the target class, and cause some code to run before and after specified methods.

A lot of IoC containers provide functionality for attaching these aspects, and the concepts of aspects, method interception, and dependency injection are harder to distinguish than they once were.

No, that's not really what AOP is for. AOP is not for implementing interfaces at runtime but for composing systems: business logic may be defined in one place for example and logging logic in another and an AOP framework will then compose the two into a bigger system. AOP is designed to cover what it refers to as cross-cutting concerns, that is functionality that is required by many objects within a system but which is not core to the concerns of those objects.

AOP works by intercepting calls to methods on objects and performing some action in addition to, or instead of, the actions performed by the intercepted method. The interception points are known as pointcuts and the intercepted method is the advised method, with the code being advised on the intercepted method being known as the advice.

I am only familiar with AOP via Spring.Net's AOP Framework which allows you to specify and apply pointcuts and advices both via configuration files and programmatically. Spring.Net AOP has four types of advice: before, after, around and throws which are invoked on interception of an advised method before the advised method is invoked, after it is invoked, both before and after its invocation and when an exception is thrown respectively. Whether applied via configuration or programmatically, the advised method has no knowledge of Spring.Net AOP or even that it has been advised. The advised method must however have some kind of implementation to intercept so your example would not work.

The Spring.Net documentation is very readable and is very good at explaining AOP in general and Spring.Net's implementation of AOP in particular and contains many examples. It is well worth a look even if just to understand AOP a bit better.