桥接模式-BRIDGE

对桥接模式感兴趣，是因为公司业务上需要桥接Html5和ReactNative两个平台。桥接模式最典型的应用是用来解决平台的差异实现。

桥接模式层次如下图：

业务
|
抽象父类—实现父类
| |
抽象子类 实现子类

函数式表达：
业务=抽象父类(抽象子类()).实现父类(实现子类())

本质上只是：
抽象类对象把部分业务请求转发给实现类对象。

桥接模式描述：
抽象管理通用代码，实现管理变化代码。
父类引用完成分离，子类替换完成扩展。
通用代码与变化代码各自演化互不影响。

缺点：
业务要决定子类组合。
每使用一个桥接元素都要增加一次函数调用，影响性能。
增加复杂度，更难阅读理解。

与直接继承相比：
关系不可变用继承，关系不确定用桥接。

桥接模式的好处：
通用代码与变化代码分离，方便各自演化。
解决多层继承引起的类爆炸。
运行时动态耦合。
隐藏实现。

中介模式-MEDIATOR

为什么要用中介模式？

职责单一的代码有很多好处，方便复用，方便扩展，方便测试。但，如果把代码分解成职责单一，就会有很多块。面向对象的设计中，表现为类爆炸。完成一个行为，需要有太多太多类互相交互共同完成。很容易演变成多对多的关系，代码也随之变得复杂很多。

解决这类问题，最根本的本质在于把多对多关系，转变为一对多，甚至是一对一的关系。

之前聊过的桥接模式，把一个类里面多对多的关系，转化为类外部的多个类之间的多对一关系。现在和大家聊的中介模式，把多个类的多对多的关系，转化为一对多的关系。从而让代码的职责更为单一，更利于复用、扩展、测试。

目前，以我自己现有的认知而言，多对多，好像只能载化为一对多。总得有一个类去做协调的工作。只是把多中心，转变为单中心而已。虽然通过一些技术手段可以实现假的一对一，但底层还是通过一对多来实现的。

怎么用中介模式？

很多设计模式都是通过建立一个转发的中间层的解决问题。中介模式就是在一堆通信对象中间建一个请求转发中心来解决多对象的通信问题。每个对象只需要与中介通信，中介负责请求的转发。有些实现，可能会在转发做一些加工处理，但原则上，在中介上做的加工处理，越少越好。以免随着业务的扩展，把中介发展成一个超级类，这样一来，引入的中介反而会成为一个很难解决的问题。

中介模式采用如下结构：
中介父类——引用 同事父类
| |
中介子类 引用——同事子类

同事子类通过同事父类向中介父类发出请求。中介子类向同事子类转发请求。中介子类与同事子类之间的通信可以通过观察者模式或者通知接口来实现。

同样是协调多个对象完成单个对象不可能完成的协作行为，同样是一对多，外观模式的通信是单向的，中介模式的通信是多向的。

资源在并发请求中怎么保护？

中介模式，因为可能存在多个同事同时请求资源的情况，需要做并发保护，确保其所管理的对象不被损坏，保证中介者的方法返回的结果是一致的。可以同时读，不可以同时写。那同时有很多写操作怎么办？排队。

可以进一步优化吗？

标准实现里，中介需要知道管理的对象方法以便调用。这会降低复用。为解决问题，需要把中介模式通用化，其中有两个方案，命令模式和发送消息。

命令类定义对象需要执行的命令。命令中介定义转发命令方法，接收命令对象和同事对象，把除调用者以外的同事对象一一传给命令执行方法，捕捉命令执行结果返回给调用者。同事对象都继承同一个基类或协议，命令中介无法协调不同类型的同事对象。

发送消息方案锁定对象方法，提供充分信息，以获得所需结果。好处是可以使用同一个中介管理不同类型的同事对象。但需要所有相关对象都理解同一组消息类型，以便以一致的方式响应消息。消息同事协议定义中介者用来识别消息发送者的属性，定义处理消息方法，接收消息类型和数据参数。消息中介管理所有对象状态，定义发送消息方法。

有什么陷阱？

不要让同事对象直接定位或者依赖其它同事对象，保证所有同事对象只通过中介者来通信。不要让中介和同事遵循同一协议，把同事对象与中介对象间变成同类通信。

还有别的吗？

说到中介，大家肯定也很熟悉生活中遇到的各种各样的房产、婚恋、业务中介。中介提供的服务是，你需要报你的要求，他帮你去寻找和匹配你所需要的资源。作为活动的中心，中介因为掌握了全局信息而获得信息优势。
为了避免被有信息优势的中介裹协，我们往往需要多找几个中介。让中介去竞争自己的资源，从而为自己找到更好的价格和服务。
同样的，为了避免对象请求一直得不到资源分配的情况发生，我们可能需要把等效资源切分开，每个较小的中介去管理小块资源，当对象请求一个中介没有得到资源分配后，可以尝试去其它中介请求。

我微信号：qingxingfengzi