研磨设计模式之装饰模式-4(转)

3.3  装饰模式和AOP

        装饰模式和AOP在思想上有共同之处。可能有些朋友还不太了解AOP，下面先简单介绍一下AOP的基础知识。
1：什么是AOP——面向方面编程
        AOP是一种编程范式，提供从另一个角度来考虑程序结构以完善面向对象编程（OOP）。
        在面向对象开发中，考虑系统的角度通常是纵向的，比如我们经常画出的如下的系统架构图，默认都是从上到下，上层依赖于下层，如图5所示：

                                          图5  系统架构图示例图
        而在每个模块内部呢？就拿大家都熟悉的三层架构来说，也是从上到下来考虑的，通常是表现层调用逻辑层，逻辑层调用数据层，如图6所示：


图6  三层架构示意图

        慢慢的，越来越多的人发现，在各个模块之中，存在一些共性的功能，比如日志管理、事务管理等等，如图7所示：
 

                                         图7  共性功能示意图

        这个时候，在思考这些共性功能的时候，是从横向在思考问题，与通常面向对象的纵向思考角度不同，很明显，需要有新的解决方案，这个时候AOP站出来了。
        AOP为开发者提供了一种描述横切关注点的机制，并能够自动将横切关注点织入到面向对象的软件系统中，从而实现了横切关注点的模块化。
        AOP能够将那些与业务无关，却为业务模块所共同调用的逻辑或责任，例如事务处理、日志管理、权限控制等，封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可操作性和可维护性。
        AOP之所以强大，就是因为它能够自动把横切关注点的功能模块，自动织入回到软件系统中，这是什么意思呢？
        先看看没有AOP，在常规的面向对象系统中，对这种共性的功能如何处理，大都是把这些功能提炼出来，然后在需要用到的地方进行调用，只画调用通用日志的公共模块，其它的类似，就不去画了，如图8所示：


                    图8  调用公共功能示意图

        看清楚，是从应用模块中主动去调用公共模块，也就是应用模块要很清楚公共模块的功能，还有具体的调用方法才行，应用模块是依赖于公共模块的，是耦合的，这样一来，要想修改公共模块就会很困难了，牵一而发百。
        看看有了AOP会怎样，还是画个图来说明，如图9所示：


                 图9  AOP的调用示意图

        乍一看，跟上面不用AOP没有什么区别嘛，真的吗？看得仔细点，有一个非常非常大的改变，就是所有的箭头方向反过来了，原来是应用系统主动去调用各个公共模块的，现在变成了各个公共模块主动织入回到应用系统。
        不要小看这一点变化，这样一来应用系统就不需要知道公共功能模块，也就是应用系统和公共功能解耦了。公共功能会在合适的时候，由外部织入回到应用系统中，至于谁来实现这样的功能，以及如何实现不再我们的讨论之列，我们更关注这个思想。
        如果按照装饰模式来对比上述过程，业务功能对象就可以被看作是被装饰的对象，而各个公共的模块就好比是装饰器，可以透明的来给业务功能对象增加功能。
        所以从某个侧面来说，装饰模式和AOP要实现的功能是类似的，只不过AOP的实现方法不同，会更加灵活，更加可配置；另外AOP一个更重要的变化是思想上的变化——“主从换位”，让原本主动调用的功能模块变成了被动等待，甚至毫不知情的情况下被织入了很多新的功能。

2：使用装饰模式做出类似AOP的效果
        下面来演示一下使用装饰模式，把一些公共的功能，比如权限控制，日志记录，透明的添加回到业务功能模块中去，做出类似AOP的效果。
（1）首先定义业务接口
        这个接口相当于装饰模式的Component。注意这里使用的是接口，而不像前面一样使用的是抽象类，虽然使用抽象类的方式来定义组件是装饰模式的标准实现方式，但是如果不需要为子类提供公共的功能的话，也是可以实现成接口的，这点要先说明一下，免得有些朋友会认为这就不是装饰模式了，示例代码如下：

/**
* 商品销售管理的业务接口
*/
public interface GoodsSaleEbi {
    /**
     * 保存销售信息，本来销售数据应该是多条，太麻烦了，为了演示，简单点
     * @param user 操作人员
     * @param customer 客户
     * @param saleModel 销售数据
     * @return 是否保存成功
     */
    public boolean sale(String user,String customer,
SaleModel saleModel);
}

 

顺便把封装业务数据的对象也定义出来，很简单，示例代码如下：

/**
* 封装销售单的数据，简单的示意一些
*/
public class SaleModel {
    /**
    * 销售的商品
    */
    private String goods;
    /**
    * 销售的数量
    */
    private int saleNum;
    public String getGoods() {
        return goods;
    }
    public void setGoods(String goods) {
        this.goods = goods;
    }
    public int getSaleNum() {
        return saleNum;
    }
    public void setSaleNum(int saleNum) {
        this.saleNum = saleNum;
    }
    public String toString(){
        return "商品名称="+goods+",购买数量="+saleNum;
    }
}

 （2）定义基本的业务实现对象，示例代码如下：

public class GoodsSaleEbo implements GoodsSaleEbi{
    public boolean sale(String user,String customer,
                      SaleModel saleModel) {
        System.out.println(user+"保存了"
                                 +customer+"购买 "+saleModel+" 的销售数据");
        return true;
    }
}

 

（3）接下来该来实现公共功能了，把这些公共功能实现成为装饰器，那么需要给它们定义一个抽象的父类，示例如下：

/**
* 装饰器的接口，需要跟被装饰的对象实现同样的接口
*/
public abstract class Decorator implements GoodsSaleEbi{
    /**
               * 持有被装饰的组件对象
           */
    protected GoodsSaleEbi ebi;
    /**
     * 通过构造方法传入被装饰的对象
     * @param ebi被装饰的对象
     */
    public Decorator(GoodsSaleEbi ebi){
        this.ebi = ebi;
    }
}

 （4）实现权限控制的装饰器
先检查是否有运行的权限，如果有就继续调用，如果没有，就不递归调用了，而是输出没有权限的提示，示例代码如下：

/**
 * 实现权限控制
 */
public class CheckDecorator extends Decorator{
    public CheckDecorator(GoodsSaleEbi ebi){
        super(ebi);
    }
    public boolean sale(String user,String customer
        , SaleModel saleModel) {
        //简单点，只让张三执行这个功能
        if(!"张三".equals(user)){
            System.out.println("对不起"+user
                +"，你没有保存销售单的权限");
            //就不再调用被装饰对象的功能了
            return false;
        }else{
            return this.ebi.sale(user,customer,saleModel);
        }
    }
}

 （5）实现日志记录的装饰器，就是在功能执行完成后记录日志即可，示例代码如下：

/**
* 实现日志记录
*/
public class LogDecorator extends Decorator{
    public LogDecorator(GoodsSaleEbi ebi){
        super(ebi);
    }
    public boolean sale(String user,String customer,
        SaleModel saleModel) {
        //执行业务功能
        boolean f = this.ebi.sale(user, customer, saleModel);

        //在执行业务功能过后，记录日志
        DateFormat df =
            new SimpleDateFormat("yyyy-MM-dd HH:mm:ss SSS");
        System.out.println("日志记录："+user+"于"+
                df.format(new Date())+"时保存了一条销售记录，客户是"
                +customer+",购买记录是"+saleModel);
        return f;
    }
}

 （6）组合使用这些装饰器
        在组合的时候，权限控制应该是最先被执行的，所以把它组合在最外面，日志记录的装饰器会先调用原始的业务对象，所以把日志记录的装饰器组合在中间。
        前面讲过，装饰器之间最好不要有顺序限制，但是在实际应用中，要根据具体的功能要求来，有需要的时候，也可以有顺序的限制，但应该尽量避免这种情况。
        此时客户端测试代码示例如下：