背景
在应用中,一个业务会有多个协作者，直接耦合会导致其中一个类的变化就会影响其它类的行为。这时最好的做法是对行为进行抽象，区分出变与不变，或者核心与外围的部分，然后定义出接口来隔离变化。
以Chromium的主文档加载为例。FrameLoader负责一个Frame的加载逻辑，从开始加载(load())或者重新加载(reload()),到结束(stopLoading())，这个过程是固定的，概括而言(即进行抽象)就是:
开始-> 发送请求->收到响应头信息 ->收到页面数据-> 完成。
但是中间过程中每个阶段可能做的事情不一样 (识别变化)，包括:
1. 请求发送前，做些准备工作，或者改变一些参数。
2. 收到响应头，判断一下响应头里如果有特殊字段，需要采取不同的行为。
等等。
一边是Frame和FrameLoader的交互，另一边则是FrameLoader与业务层的交互。这就是需要进行隔离的界面。
设计方案
Frame和FrameLoader仍然关注于加载的逻辑，需要外部的协作时通过FrameLoaderClient这个接口与具体的实现交互。外部的FrameLoaderClientImpl执行如何的操作时也完全由它们控制，比如FrameLoaderClientImpl，有些事则进一步交由再上层的模块去完成。
这种方案被大量使用，比如WebViewClient和WebWidget：
这个示例更接近于它所属的桥接(Bridge)模式,而上面FrameLoaderClient则像是一个退化的版本。
小结
这种模式就是桥接模式(BridgePattern)。
核心都是使用一个抽象的接口隔离变化，既提高了各层的内聚性，又降低它们间的耦合。符合OO原则中的:
1. 封装变化
2. 针对接口编程，而不针对具体的实现。
3. 降低交互对象的耦合度。
缺点是: 提高了复杂度。
