MVP那些事儿(5) 中介者与MVP

时间 2019-11-17

原文原文链接

这本书的实际价值也许还值得商榷。毕竟它并无提出任何史无前例的算法或者编程技术。它也没能给出任何严格的系统设计方法或者新的设计开发理论——它只是对现有设计成果的一种审视。你们固然能够将其视为一套不错的教程，但它显然没法为经验丰富的面向对象设计人员带来多少帮助。程序员

摘自GoF《设计模式：可复用面向对象软件的基础》的最后一章面试

快速回顾

MVP那些事儿(4)……在Android中使用MVC（下） MVC的各个组件经过一些规则已经组合完成，同时加入了监听机制，组成一条高效的事件传送带，让事件流转其中，在将来，咱们能够在这条带子上关键环节加入多个处理事件的方法，并把它们暴露出来供使用者自定义它们的具体功能，让其扩展最大化。学习

这张图中的每个 虚线圆点，表示着对外暴露的可操做事件的方法，在设计框架的时候，扩展性是着重要去考虑的，在事件流转中“插入”钩子方法，甚至是 钩子对象，能够说是一种经常使用的手段。

MVP

咱们以前已经经过大量的篇幅详细的介绍了MVC架构，同时也开始着手搭建一个框架，目的是就是为了能够平滑的过渡到MVP，若是你对MVC架构基本概念的理解有些模糊，或只知其一;不知其二，不妨回头耐心的看看以前的章节，毕竟MVC有不少部分是和MVP有共通性的，好比View和Model的职责等等这些，都与MVP是息息相关的，而本章的内容是将注意力放在它们之间的不一样点上，不会过多的阐述它们之间共通的部分。若是已经阅读了的朋友，结合本章内容你会很轻松的理解并抓住MVP的本质。

中介者模式（Mediator）

为了能更好的理解MVC与MVP的区别，就要把它们具象的去讨论，而不是简单的停留在抽象的层面。MVP的出现必定是解决了MVC某一方面的不足，必然算是一种提高，而这提高的过程，必然也是思想的提高，但凡涉及到设计思想，也就逃不出大众的思惟，咱们在处理一些问题时，都会碰到一些阻碍，人们在处理这些问题时为了能造福后代，少走弯路，就把这些经验流传下来，古有三十六计孙子兵法，今有GoF的二十三种设计模式，都是为了解决一些场景性的问题而制定的最优策略。因此，在MVC提高到MVP的过程当中，会不会也有前人留下的设计思想值得咱们去借鉴一下呢？在我学习MVP的时候，我发现了中介者设计模式与MVP的核心思想有很大程度的吻合，也特别想从中介者模式的这个角度去谈谈MVC与MVP之间的本质区别，其主要目的仍是但愿能经过一个具象的例子，延伸到抽象的架构上去，加深理解，因此理解了中介者模式也就更容易去理解MVP。

中介者模式的出现是为了解决对象间复杂的引用关系。为了快速get到中介者模式的核心价值，咱们引入一个场景。

场景

假设你是一个项目组的开发人员，你的角色是开发，你有不少同事，他们分别为，设计，美工，后台，需求，测试。

同事类（Colleague）

你能够把你的同事当作一个个的类，从你作为出发点，你的同事统一称之为同事类，你在别的同事眼中也是他们的同事类，大家是一类人，均可以叫作同事类，

场景描述

因为是新的项目，项目经理没有到位，同事间沟通全都是点对点，相对比较混乱，没有人负责流程。在项目进行中，项目经理到岗，他决定，全部的沟通都要先汇报到项目经理，而后再让项目经理转发命令到相应的同事。好比产品经理提出一个新的想法，先要传递到项目经理处，再由项目经理决定，到底须要开发仍是设计来参与这个需求，在这里，项目经理承担着中介者的职责，他相对于同事类来讲就是中介者类。中介者设计模式只涉及到两个角色，同事与中介者。

中介者的职责

首先，中介者的目的就是让同事类之间“永不相见”，也就是所谓的“隔离”。并负责收集传递同事间的事件，在此期间作一些流程控制。

注意：设计不当，会使得中介者变的臃肿，不易维护。

同事类的职责

中介者的同事类能够是无数个，同事类也能够有共通的行为，好比上班，下班，吃中饭。同事类也能够彻底没有共通行为，好比有一类同事，它们可能只负责编码，还有一类同事，它们可能只负责订饭，编码的不会订饭，订饭的也不会编码。

在了解中介者模式的使用场景后，咱们经过一幅图来对比一下：

没有使用中介者

使用中介者

第一张图，全部的对象都包含其余的对象，对象间关系复杂。

第二张图，全部的对象只和中介者（项目经理）交互，由中介者负责处理逻辑和转发事件

那么中介者模式和MVP架构有什么联系吗？咱们把上面的两张图简化一下，还记得咱们以前是怎么介绍MVC的架构图吗？没错，把具象的变成抽象的。

抽象化

咱们首先把同事类的个数从5个变为3个：

经过对同事类的减小，咱们生成了一张对比图，左边的图是没有使用中介者的场景，右边的使用了中介者的场景。对于左边的图是否是有些似曾相识呢？若是你们看了我以前写的文章或者对MVC有了解的话，是否是很像MVC的架构图？再看看右边的图是否是有点像MVP呢？也许有人会有疑问，像是像，但一个是模式，用来解决实际问题，而另一个是架构，不能够相提并论，固然我本身也在以前的文章里阐述过这个问题，设计模式和架构不是一个概念，解释一下，并无说中介者模式就是MVP架构，而是借鉴了中介者模式中的部分思想，起码从个数来讲，中介者同事类的个数是没有上限的，而MVP的同事只有2个，M和V，这里指的个数是同一类同事，并非全部实例化的同事。 当咱们把具象的业务场景向上抽离直到变成抽象，最终咱们发现，在中介者模式里的同事类，就如同MVC中的三个层，它们互为同事，不计耦合的成本点对点的通讯， 即Controller并无起到隔离同事的做用，它就是一个普通的同事，而在MVP中，M与V是被隔离开来的，全部的沟通都要经过P来进行，这和中介者模式的思想是很是的类似的，只不过中介者更偏向于实际的场景，更加的具象而已。

深度解读

公司不可能只有一个程序员或者产品经理，更或者是项目经理（咱们这里讨论的角色都是泛化前的，也就是接口）。举个例子，项目的过程当中不知什么缘由又换了一个项目经理，无论怎么换他的核心职责就是中介者，又或者换了一个程序员，他可能有他独有的特性，但核心仍是一个会敲代码的同事类，在现实中，这种人员调动必定会存在的，若是你们都是点对点的沟通，那么耦合是在所不免，假设一个产品经理角色依赖了最少四个以上的其余同事，当这个产品不在了，或者须要替换，那么他们之间的行为都会消失没法利用。而有了中介者，同事间的沟通是不须要知道接受方是谁，这一切都由中介者去操心。而同事类也能够不用知道具体的中介类是谁，他们之间是绝对透明的，也许次日你即时通信软件里收到的信息是来自另一个项目经理的指令，这也就是所谓的“封装/隔离”，也是接口的本质。

错综复杂的对象间关系

在中介者模式的章节里，咱们知道这个模式的核心价值观是为了解决对象间错综复杂的关系，但除此以外，它还有一个很是酷的拓展能力，这也是MVP最为重要的一个能力——可复用与可扩展性。 复用性和可扩展性才是用好MVP的关键

MVP的扩展性

咱们继续经过以前的场景来阐述MVP的扩展性，项目中一开始只开发了IOS平台的软件，这个时候公司决定增长Andoird平台，以前项目已经有了一个完整的团队，如今只须要加入一个Andoird程序员和一个熟悉Android设计的UI，由于IOS和Android程序员都有一个共同的能力，就是对接口理解，以及对设计和需求的理解是一致的，只不过他们使用的平台不同，因此在泛化程序员的时候，咱们只要把平台这一项放开便可，UI也是同样，他们使用的工具和设计稿相同，只不过切图的尺寸不一样，而产品经理、项目经理、测试工程师、后台工程师均可以直接拿来复用，而不须要另外组建一个团队，这对公司来讲是一件很是节省成本的事情，而同时，程序员组和UI组的到了能力扩展。再继续举个例子，在项目的开展过程当中，因为追赶进度，须要加班，而项目经理周六日没法加班，因而公司派了一个加班项目经理。他只有在周六日上班，因为是加班，因此加班项目经理决定下班时间从七点调整为五点，这样当项目处于加班期时，员工五点下班，咱们的项目经理都有决定下班时间的功能，而这个功能是开放的。很不巧的是，咱们的产品经理也须要一个加班产品经理，这个加班产品经理他根本不知道加班项目经理和项目经理之间的区别，他一直觉得下班时间为五点，而事实上他无需关心，一样的，加班项目经理也不知道这个产品经理是个加班产品经理，他也无需关心这一点，他们之间永远都是透明的。（仔细看这张图，慢慢体会）。

总结

咱们看似是在讲中介者，其实只是经过中介者来论述MVP架构的优点，中介者模式的出现是为了解决对象间错中复杂的关系，在没有中介者的状况下，全部对象都要认识彼此，有了中介者，它包含了整个系统的控制逻辑，中介者除了能解耦并增长对象复用外，还有如下几点好处

控制逻辑集中，职责明确让模块更加方便维护

那么MVP的出现就是为了解决MVC各个层间的一个强耦合以及扩展不灵活等问题。因此在MVP中，P能够是设计成为一个接口，M和V也能够设计成一个接口，这才能发挥MVP价值最大化。

我在刚接触设计时，因为理解不够，一上来无论三七二十一先接口化，甚至有专门的插件帮你生成接口文件，但不少时候事与愿违，整个项目到最后，接口的实现类也只用一个，甚至万年不变.

在这里多说一句，在使用MVP时，并非都要接口化的，必定要按照实际状况去设计，若是真的只有存在一个实例，看似使用了MVP架构来作设计，但只是形似而已。这个时候要思考一下，项目是否到了须要考虑复用性和扩展性到的步了呢？仍是，到不如把它们写成一团，反而少了一些没必要要的类更易于阅读和维护。

说点题外话

最近加入新公司，年末部门招人，我又责无旁贷的成了面试官，来面试的经验从两年到五年的七年以上的均有，三年以上的我基本都会问关于MVP和MVC的问题，但是能说明白的不多，即使说出来也还停留在使用层面，这其中还有的是teamleader，或项目负责人，若是这些级别的都不去考虑架构或只知其一;不知其二，难道还要期望本身下面的小弟吗？这其实也是我对本身的担心，我认为程序员作到必定的阶段，应该多去收集已知零散的知识点，对它们穿针引线，让它们相互产生关联，始终围绕在一套思想体系当中，让本身成为这套体系的受益人，并不断的改进和趋近完善，而在不断完善的过程当中必然会吸取更多的知识（比起低素质，劈腿率高这些我无需证实，勤奋仍是须要证实一下的）。