设计模式之外观模式

一、外观模式

所谓的外观模式，即一个门面类，门面类负责和各个子系统之间交互，执行相应的交互逻辑，客户端直接与门面类交互，使得客户端与各子系统之间隔离。对于子系统繁多，业务复杂的场景很实用，从上面的解释中也看到了外观模式是迪米特原则一个很好的应用，其秉承着客户端最少知道的思想。

二、业务场景

假设一个网站做活动，需要添加积分兑换礼物的业务，积分兑换礼物主要分三个模块，一个是资格校验（看一个人拥有的积分是否能获得相应的礼物），二是用积分交换礼物（积分交换礼物后，对积分进行从计算），三是兑换成功的礼物加入到物流系统并得到订单号。这里我们可以使用外观模式，设计一个兑换礼物的外观类，让外观类处理礼物兑换过程中的逻辑，留一个简单的接口给客户端调用即可。具体代码如下：

 

从上面的类图可以看出这严格来说算不上绝对的外观模式，外观模式应该与子系统之间完全解耦合，但是类图显示客户端不仅与门面类存在依赖关系，还与各系统之间存在着依赖关系，由于上面是模拟的，我们需要在客户端Test类中创建各系统的对象，做下面一个小小的修改，假设各子系统对象在门面对象初始化时就已经创建好：

修改后会出现上面这个类图，这就非常符合外观模式了。我们在这里实现的门面类没采用抽象的形式，如果系统需要修改与子系统的交互逻辑，只能修改门面类，这样违背了开闭原则。如果系统业务逻辑比较稳定，长时间不会变化，这样实现是可以的，如果系统业务逻辑变化比较快，我们可以写一个抽象类，让门面类继承该抽象类，实现不同的逻辑就继承该抽象类重写方法，这样系统的扩展性就比较强，符合迪米特原则的同时也符合开闭原则。