小more设计模式———外观模式

格式正确版本请点击 ：http://note.youdao.com/noteshare?id=62a72a5f62be1e95748051c0a34f50e9

1、场景

没过多久，公司为了简化和降低开发人员重复写相同代码的工作量。打算开发一个代码生成器的应用。在开发一个模块之前。只需要简单的配置一下，工具就可以自动生成模块的基本结构——增、删、改、查。这样开发人员就可以把主要精力放到具体业务功能的实现上。不必重复性的做相同的增、删、改、查等工作。因为现有的项目中，基本的增加、删除、修改、查询模块都有了。项目经理让小more实现一个这样的工具demo。要求：使用代码生成器生成出来的代码都具有基本的三层结构，也就是包涵表现层、逻辑层、数据层。同时，代码生成工具还需要一个配置器，用来告诉代码生成工具，生成的模块需要具体生成那一层的代码？还是三层代码都生成。具体的模块示意图如下：

小more经过几天的研究实践，写出如下代码：

（1）描述配置管理model：

(2)然后小more实现了配置管理的实现：

(3)然后小more开始实现生成表现层、逻辑层、数据层的代码。实现逻辑家大体一样，都是先获取配置文件的内容，然后按照配置来生成相应的代码。表现层代码如下（注：示例代码只用表现层的的来说明）

大功告成，小more兴致冲冲的写了一个client调用的demo。准备交给同事使用自己的“成果”。

然后项目经理在review小more代码功能时，查看客户端调用方式之后，告诉小more。针对这种情况不应该这么做。应该采用外观模式来解决。同时指出小more的代码不合理之处：

• 客户端如果想生成代码，那么会和生成代码的内部子模块交互
• 如果内部模块发生变化，很可能客户端也需要随着变化。耦合度太高

所以为了解决这个问题，需要采用外观模式，也就是在使用子系统的时候，既能够使用这些子系统内部的功能模块。又不需要客户端去和子系统内部多个模块交互。

2、解决方案

先来看看外观模式的基本含义：

（1）定义：

通过引入一个外观类，在这个类里面定义客户端想要的简单方法，然后在这些方法的实现里面，再由外观类分别去调用内部的多个模块来实现功能。从而让客户端变得简单，这样客户端就只需要和外观类交互了。

本质上，外观模式就是为子系统的一组接口提供一个一致的界面。Facade模式定义了一个高层接口，这个接口使得子系统更加容易使用。

（2）模式的结构

• Facade：定义子系统的多个模块对外的高层接口，通常需要调用内部多个模块，从而把客户的请求代理给适当的子系统模块对象。
• 模块：接收Facade对象的委派任务，真正实现功能，各个模块有可能交互

注：Facade应该知道各个模块，但是各个模块不应该知道Facade

小more经过外观模式的学习，重构了自己的代码：

首先定义一个Facade外观类：

其它类没有变化，接下来客户端调用外观类就可以了。

3、模式分析

外观模式的目的不是给子系统添加新的接口，而是为了让外部减少和子系统内多个模块的交互，松散耦合。从而让外部更加容易的使用子系统。但是，外观是当作子系统对外的接口出现的，虽然也可以在里面定义一些子系统没有的功能，但是不建议这么做，因为外观应该就是包装子系统的功能而已，它不应该拓展功能。

（1）本质——封装交互、简化调用

Facade封装了子系统外部和子系统内部多个模块的交互过程，从而简化外部调用。通过外观，子系统为外部提供一些高层接口。

（2）对设计奖原则的体现——最少知识原则

如果不使用外观模式，客户端需要和子系统内部多个模块交互，也就是说他们之间存在依赖关系，这样在维护方面的成本是很大的。

（3）何时选用外观模式

• 希望为一个复杂的子系统提供一个简单的对外接口
• 如果构建多层结构的系统，可以考虑使用外观模式，使用外观对象作为每层的入口，这样可以简化层间的调用，也可以松散层和层之间的依赖关系。

2017年12月30日 下午 17:35

写于北外教室