在软件系统设计的时候，我们需要把一个大的系统按照业务功能进行拆分，做到高内聚、低耦合。
但是呢，拆分之后会产生一些通用性的东西，比如日志，安全，事务，性能统计等，这些非功能性需求，横跨多个模块。最low的一种写法如下：
public class PlaceOrderCommand {
public void execute(){
//记录日志
logger.debug("...");
//性能统计
PerformaceUtil.startTimer(...);
//权限检查
if(!user.hasPreviledge(...)){
抛异常
}
//开始事务
beginTransaction();
//真正的业务代码
commitTransaction();
PerformanceUtil.endTimer(...);
logger.debug("...");
}
}
为什么说上面这种方式low呢，主要是因为它把日志、安全、事务、性能统计这些非业务相关的代码和业务代码完全耦合在了一起，每个类都得这么写，徒劳无功，繁琐重复。
1. 模板方法模式
由此引入一种牛逼的处理方式，叫做模板方法模式。在父类中将乱七八糟的非功能性代码写好，子类去实现相应的抽象方法就好啦。
public abstract class BaseCommand{
public void execute(){
//记录日志
logger.debug("...");
//性能统计
PerformaceUtil.startTimer(...);
//权限检查
if(!user.hasPreviledge(...)){
抛异常
}
//开始事务
beginTransaction();
//真正的业务代码
doBusiness();
commitTransaction();
PerformanceUtil.endTimer(...);
logger.debug("...");
}
public abstract void doBusiness();
}
class PlaceOrderCommand extends BaseCommand {
@Override
public void doBusiness() {
//下单操作
}
}
class PaymentCommand extends BaseCommand {
@Override
public void doBusiness() {
//执行支付操作
}
}
//执行代码
BaseCommand command = new PlaceOrderCommand();
cmd.execute();
子类只需要关注业务逻辑就好啦，是不是很清爽？
但是这也有问题，就是我把非业务功能写了一大坨，我要是想分开描述，比如安全啊，事务啊，日志啊，我不想写在一起，就比较麻烦。我可以写多个抽象类，但是Java又是单类继承。而且，这样父类会定义一切，子类只能无条件接受，制约性比较大，比如有个子类不想加日志了，就没办法了。
2. 装饰器模式
由此引入更牛逼的一种设计模式，装饰器模式。它牛逼在可以灵活地自定义执行次序。
public interface Command {
public void execute();
}
//记录日志的装饰器
class LoggerDec implements Command {
Command cmd;
public LoggerDec(Command cmd) {
this.cmd = cmd;
}
@Override
public void execute(){
//记录日志
logger.debug("...");
//真正的业务代码
this.cmd.execute();
logger.debug("...");
}
}
//性能统计的装饰器
class PerformanceDec implements Command {
Command cmd;
public PerformanceDec(Command cmd) {
this.cmd = cmd;
}
@Override
public void execute(){
PerformaceUtil.startTimer(...);
//真正的业务代码
this.cmd.execute();
PerformanceUtil.endTimer(...);
}
}
class PlaceOrderCommand implements Command {
@Override
public void execute() {
//下单操作
}
}
class PaymentCommand implements Command {
@Override
public void execute() {
//支付操作
}
}
//执行代码
Command command = new LoggerDec(new PerformanceDec(new PlaceOrderCommand()));
command.execute();
可以随意更改包裹的内容，即代码中的红色区域，更改顺序啊，加一个减一个啊等等，灵活不已。
但是也有一些问题，就是处理日志、安全、事务、性能统计的类为啥要实现业务接口（Command）呢？这在道理上面说不通啊。还有就是，没有实现业务接口，也想实现非业务功能，那应该怎么办呢？
3. AOP
AOP是Spring框架中很牛逼的一个组成，另外一个是IoC。把非功能性代码和业务代码完全隔离开来，让其正交。
把业务代码看成面包，那么非功能性代码就是一个个切面，方便灵活切入，这就是面向切面编程。
定义一个切面类，就是一个普通类。
public class Transaction {
public void begin(){
//开始事务
}
public void commit(){
//提交事务
}
}
定义一个切入点，就是com.nonfunction包下面的所有类的execute()方法。
定义一个通知，就是在方法调用之前执行啊，还是在方法调用之后执行啊。
我们想做的就是，对于com.nonfunction包下面的所有类的execute()方法，在调用之前执行开始事务的方法，在调用之后执行提交事务的方法。
这里以XML隔离为例（建议用注解的方式）：
<bean id="tx" class="com.nonfunction.Transaction" />
<aop:config>
<aop:aspect id="txAspect" ref="tx">
<aop:pointcut id="placeorder" expression="execution(public * com.nonfunction.*.execute(..))"/>
<aop:before method="begin" pointcut-ref="placeorder"/>
<aop:after method="commit" pointcut-ref="placeorder"/>
</aop:aspect>
</aop:config>
以上的方式，便可以达到完全的隔离。
但是呢，由于Java是静态强类型语言，编译成Java类以后，运行时通过反射可以查看类的信息，但是对编译好的类进行修改是不可能的。
咋办？
第一种方式就是修改现有类，在编译的时候把非功能性代码和业务代码编译到一起，这样改变业务类了，扑街。
第二种方式生成代理类，这也是用的最多的，让代理类变成增强类，原来的业务类不用改变，客户操作的是代理类对象。
那么怎么生成代理类呢，一种是使用Java自己的动态代理技术，一种是CGLib。
参考我的这篇博客吧：https://www.cnblogs.com/DarrenChan/p/9958421.html
所谓的Spring容器，就是帮你生成一个代理类，我们给它要对象，它就给你生成一个代理对象，但是我们不知道啊，还以为是原来业务类的对象。