Aop学习笔记系列一

一、Aop解决了什么问题?

1、在说解决了什么问题之前,先介绍一些关键的知识点

a、功能需求:功能需求指项目中的增值需求，比如业务逻辑，UI，持久化（数据库）。

b、非功能需求:项目中次要的,但却不可缺少的元素,如日志记录,安全,性能和数据事务等等。

2、横切关注点

它是推动Aop发明的主要因素之一,横切关注点是应用与一个系统的多个部分的片段功能(相当于一个功能应用于系统的多个地方),横切关注点和非功能性需求有许多重叠:非功能性需求经常横切应用程序的多个部分。举例:如果有两个方法a和b,如果都要记录日志c,那么就必须在a和b中放置c,这里的c就是横切关注点。

ok,如果你清楚了上面的知识点,下面开始说Aop解决了什么问题。

在OOP项目中,有非常多的横切关注点分布在项目中,久而久之,这种交错的代码会变的越来越难开发和维护,这是OOP技术不能捕获和解决的问题所以Kiczales和他的团队提出了Aop的概念,并将其作为OOP的一种补充,即使用"切面aspects"封装横切关注点以及允许重复使用。最终实现了AspectJ,就是今天Java开发者仍然使用的一流AOP工具。AOP官方文档

3、切面的任务:通知(Advice)

如果你理解了2的横切关注点,那么通知就是执行横切关注点的代码,比如对于横切关注点-日志功能,那么通知可能是log4net或者其他日志库的调用代码。

4、切面的映射:切入点(PointCut)

切入点就相当于在哪里放置通知(advice)的代码,也就是在哪里放置执行横切关注点的代码,下面通过一行代码来解释:

dataService.AddRecord();//dataService是DataService的实例

当确认了一个连接点和一个通知,就可以定义切面了。切面通过叫做组合（weaving）的过程工作。

5、Aop开始组合(weaving)

5.1、 在没有Aop的时候,有两点你需要知道

a、缠绕(tangling),系统的核心业务逻辑往往是和横切关注点缠绕在一起的.代码如下:

    class Moudle
    {
        //日志成员
        public void Method()
        {
            //日志记录开始
            //核心代码
            //日志记录结束
        }
    }

上面这个过程就是缠绕,横切关注点日志功能,和核心代码缠绕在一起

b、分散,当横切关注点用于多个方法和多个类时,代码分散在整个应用中.代码如下:

    class Moudle
    {
        //日志成员
        public void Method()
        {
            //日志记录开始
            //核心代码
            //日志记录结束
        }
    }
    class Moudle1
    {
        //日志成员
        public void Method()
        {
            //日志记录开始
            //核心代码
            //日志记录结束
        }
    }

当横切关注点出现在了两个及以上的类或者方法中,这种形式就叫做分散,因为代码分散在整个应用中。

c、违反"单一职责"原则,一个类应该只有一个要修改的理由,不能因为类中参杂着的横切关注点的变化,而去修改他,这样的类设计是不合理的.

d、反模式:反模式是软件工程已确认的一种模式，例如你可以在“Gang of Four book”（全名是：设计模式：可复用面向对象软件的基础）中找到任何模式，跟那些好的模式不同，反模式会导致bug，产生昂贵的维护费用以及令人头疼的问题。

e、横切关注点的增多,如果你不及时采用DI或者装饰着模式或者Aop,那么你就会一直的处于复制黏贴的状态,从而违反了Don't Repeat yourself(DRY)原则!

5.2、解决方案

通过DI(依赖注入),代码如下:

    class Moudle
    {
        //_核心成员
        //_日志成员

        public Moudle(//日志接口 成员)    这里将日志接口通过DI注入进来
        {
            //this._日志成员=成员;
        }
        public void Method()
        {
            //_日志成员.日志记录开始
            //核心代码
            //_日志成员.日志记录结束
        }
    }

通过代码发现,即使使用了依赖注入,代码仍然是缠绕的。

通过通过DI(依赖注入)+装饰者,代码如下:

    class MoudleDecorator
    {
        //_realmoudle
        //_日志成员

        public MoudleDecorator(//Moudle moudle,日志接口 成员)    这里将日志接口通过DI注入进来
        {
            //this._realmoudle=moudle;
            //this._日志成员=成员;
        }
        public void Method()
        {
            //_日志成员.日志记录开始
            //moudle.Method();
            //_日志成员.日志记录结束
        }
    }

    class Moudle
    {
        public void Method()
        {
            //核心代码
        }
    }

ok,我们发现装饰着能很好的解决问题,但是如果这种装饰类一多,这个代码量好像又上去了,所以又开始重复造轮子了,所以当超过3个装饰者的时候,就可以考虑改用Aop的切面了。

so,终极方案Aop登场,先看图

Aop就是为了解决上面的问题,下面使用Aop对上面的代码进行重构

代码如下:

    class Moudle
    {
        //[LoggingAspect]
        public void Method()
        {
            //核心代码
        }
    }

    class LoggingAspect
    {
        //_日志成员
        public void LoggingAspect(//日志接口 成员)  通过依赖注入
        {
            //this._日志成员=成员;
        }

        void OnEntry()
        {
            //日志记录开始
        }

        void OnSuccess()
        {
            //日志记录结束
        }
    }

通过Aop重构之后的代码更易于管理,更不容易出bug,如果你的Aop工具类库是稳定的话,代码的可读性也更强,更容易维护,降低维护的开销,如果使用Aop重构代码将横切关注点单独封装到一个切面类中,你就不用到处修改代码,只需要在一个类中修改就可以了。

下面是一个伪代码类，由于横切关注点而没有遵守单一职责原则：

public class AddressBookService
{
    public string GetPhoneNumber( string name )
    {
        if ( name is null )
            throw new ArgumentException( "name" );
        var entry = PhoneNumberDatabase.GetEntryByName( name );
        return(entry.PhoneNumber);
    }
}

虽然上面的代码阅读和维护都相当简单，但是它做了两件事：一是检查传入的name是否是有效的；二是基于传入的name找到电话号码。虽然检查参数的有效性和服务方法相关，但是它仍然是可以分离和复用的辅助功能。下面是使用AOP重构之后的伪代码：

public class AddressBookService
{
    [CheckForNullArgumentsAspect]
    public string GetPhoneNumber( string name )
    {
        var entry = PhoneNumberDatabase.GetEntryByName( name );
        return(entry.PhoneNumber);
    }
}
public class CheckForNullArgumentsAspect
{
    public void OnEntry( MethodInformation method )
    {
        foreach ( arg in method.Arguments )
            if ( arg is null )
                throw ArgumentException( arg.name )
    }
} 

这个例子中的OnEntry方法多了个MethodInformation参数，它提供了一些关于方法的信息，为的是可以检测方法的参数是否为null。虽然这个方法微不足道，但是CheckForNullArgumentsAspect代码可以复用到确保参数有效的其他方法上。

public class AddressBookService
{
    [CheckForNullArgumentAspect]
    public string GetPhoneNumber( string name )
    {
        ...
    }
}
public class InvoiceService
{
    [CheckForNullArgumentAspect]
    public Invoice GetInvoiceByName( string name )
    {
        ...
    }

    [CheckForNullArgumentAspect]
    public void CreateInvoice( ShoppingCart cart )
    {
        ...
    }
}
public class PaymentSevice
{
    [CheckForNullArgumentAspect]
    public Payment FindPaymentByInvoice( string invoiceId )
    {
        ...
    }
}

这样一来，如果我们想要修改和Invoice相关的东西，只需要修改InvoiceService。如果想要修改和null检测相关的一些事情，只需要修改CheckForNullArgumentAspect。涉及到的每个类只有一个原因修改。现在我们就不太可能因为修改造成bug或倒退。