我们为什么需要AOP

我们为什么需要AOP

本节简单介绍AOP的概念，解释我们为什么需要AOP。

AOP是Object Oriented Programming（OOP）的补充。

OOP能够很好地解决对象的数据和封装的问题，却不能很好的解决Aspect（"方面"）分离的问题。下面举例具体说明。

比如，我们有一个Bank（银行）类。Bank有两个方法，deposit（存钱）和withdraw（取钱）。

类和方法的定义如下：

// Code 2.1 Bank.java
class Bank{
public  float deposit(AccountInfo account,  float money){
   //  增加account账户的钱数，返回账户里当前的钱数
}

public  float withdraw(AccountInfo account,  float money){
   //  减少account账户的钱数，返回取出的钱数
}
};

这两个方法涉及到用户的账户资金等重要信息，必须要非常小心，所以编写完上面的商业逻辑之后，项目负责人又提出了新的要求--给Bank类的每个重要方法加上安全认证特性。

于是，我们不得不分别在上面的两个方法中加入安全认证的代码。

类和方法的定义如下：

// Code 2.2 Bank.java
class Bank{
public  float deposit(AccountInfo account,  float money){
   //  验证account是否为合法用户
   //  增加account账户的钱数，返回账户里当前的钱数
}

public  float withdraw(AccountInfo account,  float money){
   //  验证account是否为合法用户
   //  减少account账户的钱数，返回取出的钱数
}
};

这两个方法都需要操作数据库，为了保持数据完整性，项目负责人又提出了新的要求--给Bank类的每个操作数据库的方法加上事务控制。

于是，我们不得不分别在上面的两个方法中加入安全认证的代码。

类和方法的定义如下：

// Code 2.3 Bank.java
class Bank{
public  float deposit(AccountInfo account,  float money){
   //  验证account是否为合法用户
   //  Begin Transaction
   //  增加account账户的钱数，返回账户里当前的钱数
   //  End Transaction
}

public  float withdraw(AccountInfo account,  float money){
   //  验证account是否为合法用户
   //  Begin Transaction
   //  减少account账户的钱数，返回取出的钱数
   //  End Transaction
}
};

我们看到，这些与商业逻辑无关的重复代码遍布在整个程序中。实际的工程项目中涉及到的类和函数，远远不止两个。如何解决这种问题？

我们首先来看看OOP能否解决这个问题。

我们利用Design Pattern的Template Pattern，可以抽出一个框架，改变上面的例子的整个设计结构。

类和方法的定义如下：

// Code 2.4 Base.java
abstract class Base{
public  float importantMethod(AccountInfo account,  float money){
   //  验证account是否为合法用户
   //  Begin Transaction
  
   float result = yourBusiness(account, money)

   //  End Transaction
   return result;    
}

protected abstract  float yourBusiness(AccountInfo account,  float money);
};

Code 2.5 BankDeposit.java
class BankDeposit extends Base{ 
protected  float yourBusiness(AccountInfo account,  float money){
   //  增加account账户的钱数，返回账户里当前的钱数
}
};

Code 2.6 BankWithdraw.java
class BankWithdraw extends Base{ 
protected  float yourBusiness(AccountInfo account,  float money){
   //  减少account账户的钱数，返回取出的钱数
}
};

这里我们用一种很勉强的方法实现了认证和事务代码的重用。而且，有心的读者可能会注意到，这种方法的前提是，强制所有的方法都遵守同样的signature。

如果有一个转账方法transfer(AccountInfo giver, AccountInfo receiver, float money)，由于transfer方法的signature不同于yourBusiness的signature，这个方法无法使用上面的框架。

这个例子中提到的认证，事务等方面，就是AOP所关心的Aspect。

AOP就是为了解决这种问题而出现的。AOP的目的就是--Separation of Aspects (or Separation of Concerns).