我用过的设计模式（6）-- 门面模式

在这里插入图片描述

门面模式

什么是“门面”？门面就是让你一看就知道里面可以提供什么东西，但是你又不会知道它是如何提供的。

门面模式是什么？

在这里插入图片描述

我知道，这张图也看不明白在讲什么。

门面模式的定义已经呼之欲出了：要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。

优点：高内聚，松耦合。安全，不通过门面上提供的方法，休想访问模块内部。

说说我是如何在项目中使用这个模式的吧。

这次带班的时候做了这么一张图：

在这里插入图片描述

门面上的东西呢，是那些UI界面，而门后面的东西，则是各个算法类，用户能接触到的只有UI，UI类也无法直接接触到算法类，只能向任务调度类发出信号，由任务调度类接收信号并作出统筹，这就是我的“门面模式”。

门面模式是个很好的模式，很符合面向接口编程，遵守了依赖倒置原则、迪米特法则等，当然，有些书说违背了开-闭原则，我个人认为，门面模式并不妨碍拓展，只要把基类抽取好，新功能只需要继承或依赖与基类即可。

以下是一段教科书式的评判：（外观模式 == 门面模式）

外观模式的优点非常显而易见，对客户屏蔽了内部系统实现，客户的接入成本大大降低，耦合度也变得简单。并且，子系统的变更，对客户的影响也降低，虽然用户也需要修改代码，但是大多时候只需要修改外观即可。同时，外观模式虽然提供了一个统一的入口，但并不妨碍用户直接使用子系统，使用更加复杂的功能。当然，凡事有利必有弊，外观设计模式存在什么问题呢？虽然外观模式提供了一个入口，但是并不能阻止业务方直接调用子系统，可能会给人这样一种感觉，业务方一定是这么用的，不会产生bug，从而让人麻痹，所以，使用外观模式，同时也要对子系统做好保护。其次，外观模式实际上违背了设计模式中的开闭原则，如果我们要修改业务逻辑，常常业务方也需要进行代码修改。那么，什么样的情况下适合使用外观模式呢？如果我们的调用方用到的场景都是一样的，但我们的子系统又非常地复杂，我们可以考虑封一个外观，让业务方更容易接入。

各执一词，诸位看自己的感觉吧，毕竟书是死的，人是活的。

今天不想上代码，这个模式，只可意会。

在这里插入图片描述

在这里插入图片描述