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