Remove code smell with AOP

During the last years you have probably heard about Aspect Oriented Programming (AOP). Different people like or don’t like AOP. I’m one of them who like AOP. As you may now VB.Net and C# are object orientated languages and with object oriented programming (OOP) you want to reduce code duplication, code duplications smells badly. If you need to do code duplication you are probably doing something wrong with the implementation of your domain model. With OOP you can generally eliminating code duplication, but there are some cases where we can’t avoid it, for example take a look at this code:

public class MyClass
{

       public void MyBusinessMethod1()
       {
             CheckSecurity();
             //Place your code here
       } 

       public void MyBusinessMethod2()
       {
             CheckSecurity ();

             //Place your code here
       } 

       public void CheckSecurity ()
       {
            //Place the code for the security check here
       }
}

The code above has code duplications, where CheckSecurity method is added to each business method. This code duplication is not only painful to write, it could also make the code smell bad and make the code less maintainable. With the refactoring Move Method "A method is, or will be, using or used by more features of another class than the class on which it is defined", the CheckSecurity method could be moved into the infrastructure and the new class where the method is located will be the only place where the CheckSecurity is located. Centralization of code will make it easier to maintain the code. Even if you use the Move Method, the MyClass still use code duplication. Unfortunately, OO doesn’t help us removing the code duplication. You could of course use code generation to manually avoid adding the CheckSecurity to each method where the security check needs to be done.

AOP crosscutting can be used to address concerns such as the security checks and of course other application specific concerns too, for example, you could make Lazy Load work without needing to have a dependency to your Repository or data mapper within the domain objects. With AOP, you could remove the code duplication from the code example above, and create a method interceptor where you add the CheckSecurity method. The following is a pseudo code of an interceptor:

public class MySecuirtyInterceptor : MethodInterceptor
{
      public object Invoke(MethodInvocation invocation)
      {
            CheckSecurity (); 

            //Call next interceptor
            Return invocation.Proceed();
      }
}

By using an AOP framework where you could define a set of methods (pointcuts) that should use the security interceptor, you could easy remove the code duplication, and remove the security concern from the developer, and add it later, if it’s required. The The MyClass in the first example could look like this if we use AOP and the MySecurityInterceptor above:

public class MyClass
{
       public void MyBusinessMethos1()
       {
             //Place your code here
       }

       public void MyBusinessMethos2()
       {
             //Place your code here
       }
}

Developers don’t need to add the CheckSecurity method. If we need to have a security check before executing the method, you could add a pointcut later for the methods that should call the CheckSecurity. Some sophisticated AOP frameworks can use regular expression or other wildcard syntax for the pointcuts. Pointcuts is a set of Method, Fields or Throws (When a particular exception is thrown) that should invoke the interceptor method. Those pointcuts could for example be specified within a XML file.

You can also use AOP to do some logging or other operations before or after a method has bean invoked, or a field has been set, or even when en exception was thrown. The developer who are creating the business methods, don’t need to call a method that will for example log a message, it’s something that could be specified within an XML file. By using AOP you could solve problems that could not be done with OOP. You can not only reduce the smell of bad code, you could also reduce time it takes to add the duplication of codes etc. I hope this post gave you some more information about how you can use AOP to solve some problems that can’t be easily done with OOP.

4 Comments

  • OK, that "pseudo code" code example is a start. Can we see a simple, real life, example of: this is how you'd normally do it, and this is how you do it with AOP? Every time I try to read about AOP I'm thrown into this massive never-ending novel reading. I need something quick and dirty to show me why it's so great. If you can convince me that it is then I'll spend the time to read the novel as well...

  • @PBZ

    The code that Fredrik have in his example is almost 100% compatible with our framework NAspect.

    But our interceptors are called IAroundInterceptor instead of MethodInterceptor.
    That, and the methods that should be intercepted needs to be virtual.

    So you could take a look at NAspect , www.puzzleframework.com
    There are samples that does pretty much what Fredrik describes there.

  • Hey this is nice article and good efforts by you. But we will appreciate if you can provide us with the small live example with implementation, so that we can get a clear view about AOP. We are waiting for your reply with example implementation.

    Thanks in Advance

  • A useful example would be the Transaction facility of Castle Framework.
    You decorate your method with [Transaction] and everything in this method happens in a transaction.

Comments have been disabled for this content.