门面模式和调停者模式
门面模式 Facade
门面模式，是指提供一个统一的接口去访问多个子系统的多个不同的接口，它为子系统中的一组接口提供一个统一的高层接口。使得子系统更容易使用。
通俗解读
当需要提供给其他人功能时，实际代码需要做很多调动，而这样的工作又有很多类。而这每一类之间又存在细节的不同，如果实质编码结构如下：
案例说明
对于业务或者算法进行实现后，软件模块清晰，代码结构如下图所示
但是，在正常业务上现在存在调用的方式，如：
- 扩展业务一：现在需要执行完模块一后执行模块三
- 扩展业务二：执行完模块五后执行模块一
- 扩展业务三：执行模块一后执行模块三再执行模块四
- …等等、等等
我们会发现软件代码在业务不断扩展后会变成如下结构
而如下结构可以称之为代码腐烂，随着业务的增长，代码的可读性不断下降，说的不好听一点就是代码结构思想优秀，但是代码质量很差，这就是部分公司代码结构混乱的原因之一(没有其他意思，我现在的一个代码历经10年一开始不做重构升级代码就是这样的，其中的一个cs文件只有一个类，而这个类有8000行代码)
而当我们扩展时可以使用门面模式进行管理是，其将会非常清晰：
门面模式的最杰出代表使用就是消息中间件
调停者模式 Mediator
调停者模式是软件设计模式的一种，用于模块间解耦，通过避免对象互相显式的指向对方从而降低耦合。
调停者模式相较门面模式的区别在于：
- 门面模式针对的是别人使用你的模块，这里面有对于你的顺序、业务有一定的修改扩展的情况。
- 调停者模式更多的是在软件内部，当软件内部对象或模块之间相互通信时如何调用[解耦]
案例说明
大家都是开发人员，在工作中能分为开发小组、需求产品组、测试小组。当需求组中有需求需要分配给开发人员，开发小组人员需要深入了解业务需求，开发完毕之后提交需求、需求提交测试，测试反馈开发小组时。
原始代码结构如下：
看着复杂其实不复杂，其实可以转变为这样的：
当世界不发生变化的时候他就是和谐的，但是需求总会发生改变，从哲学上说世界上不变的东西只有变化，当上述需求发生变化时：
- 开发组xiaocai现在开发一个新的模块或者开发模块中存在部分需求与需求组小白对接
- 需求组01发现存在问题，需要和产品组确认也需要和开发组其他人员对接
- …不断变化的时候
在此情况下等待一定时间之后我们可以看到如下结构，当结构足够复杂是可能下图还可以抢救一下，使其结构清晰
但是足够复杂之后，神也救不了。那么我们应该如何修改结构图呢？[仅仅对于次案例]
- 我们应该抽象出一个抽象成员
- 需要将业务或者人员的连接清晰固化
其实大多数调停者模式的示意图是如下，但是领域或者说需求业务需要结合实际情况，软件设计和架构没有银弹，软件设计需要借鉴设计模式但是还是需要融会贯通，结合实际具体问题具体分析。