中介者模式 Mediator
意图
用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式的相互引用，从而使其耦合松散，而且可以独立的改变他们之间的交互。
场景
假设一个包含按钮、菜单和输入域的弹出，通常弹出框中各个组件之间存在依赖关系，比如，当输入域为空时某个按钮不能使用；在输入域中属于内容会自动选择并展示一个或多个列表条目；一旦正文出现在输入域中，其他一些按钮可能就变得能够使用了，而这些按钮允许用户做一些操作，比如改变或删除正文内容等。
- 从事图形界面类软件(Android、PC、Mac、iOS等操作系统应用软件)开发的人似乎从来不需要担心这个问题，因为虽然我们面临着大量的类似场景，但是我们似乎从来没有为这种场景犯愁过。其实在图形界面的开发工作中我们不可避免的会用到该模式，也正因为此，我们才从不需要为这种场景去发愁。拿Android来说，在Activity中将会有所有需要用到的View的引用，所有的事件将会通过Activity进行中转。在这种场景下，一般用于图形界面开发的SDK都直接提供中介者用于具体操作。
- 或许你会问，除了这样还有其他方式吗？有，但是毫无疑问这种方式更为直观方便，易于修改。
拓展
虽然有中介者模式的天生支持，但是这样我们就高枕无忧了吗？并不是，有更多的工作需要我们开发者去做。
继续以Android为例，在Android开发中，虽然可以通过Activity作为中介者实现中介者模式对View复杂的依赖关系进行处理，但是需要注意的是，在Activity中还有其复杂的生命周期需要处理，在其生命周期中往往有更重要的信息需要去处理，比如用户数据等。很明显同时再承担各个View之间的中介将极大的加重Activity的任务量，这将造成两点主要坏处：
- 中介者作为一个连接各个类之间关系的桥梁，应该可以没有限制的去重构、或者重写一个，但是Activity因为包含了生命周期的相关处理，重构时需要小心是否影响到了生命周期中的处理内容，重写的时候需要再将生命周期处理函数重新写一遍。总结起来就是麻烦。
- View之间和Activity生命周期之间很容易产生硬性的直接的连接调用，当这个View不再存在时还需要单独去处理Activity代码，像上面说的一样，很容易伤及无辜。
很明显我们需要自己添加一种处理手段避免该现象的产生。
MVP模式虽然主要目的不仅仅是为了解决这么小的一个问题，但是他却很好的通过他的View层解决了该问题。MVP中的IViewBase接口定义了各状态下的显式效果，而作为开发者的我们可以通过不断的实现MVP中IViewBase层接口去不断地产生具有不同效果的中介者。但需要注意的是，如果通过Activity直接继承IViewBase应该减少Activity中各回调函数对View的直接调用，可以间接的去掉用MVP中的IViewBase中的方法或者其他层的接口方法间接实现需求。