Abstract Server Adapter Bridge

对于控制和实现，这三个模式体现着三个不同的层次，如果加上不使用任何模式，就是有四个层次了。

这里所说的层次，没有高低之分，只有需求的区分。如果对于一个没有任何变化的需求，而使用上Bridge模式，也同样是一个丑陋的设计。

什么是控制和实现？抄一个《ASD》中的例子，一个照明设备（灯），他有两部分。一个是开关，一个是灯泡。开关有两个操作，开和关。灯泡也有两个操作，发光或不发光。

最简单的控制和实现，只有两个类。一个控制类，一个实现类。控制类面对用户，实现类实现具体操作。这就是不使用模式的方法。

有时候，同一个控制可以搭配多种不同的实现。例如，开关可以搭配多种不同的灯，A灯、B灯、C灯，虽然都是发光或不发光，可是实现却各不相同。每种灯都有自己的类。
这时的解法也是很自然的，添加一个抽象的灯类，有两个抽象方法：发光和不发光，所有具体的灯类都从这个抽象灯类派生。开关类只和这个抽象类打交道，不关心具体灯类了。
这样就把控制类和具体的实现类分离开来了。非常简单，这就是Abstract Server模式。

使用Abstract Server模式，要求所有的具体实现类，都从同一个接口派生出来。然而有时候，这是作不到的。最典型的情况就是，我们已经有了一个不可修改的实现，比如某个第三方提供的库。
这就是说，我们有两个相似但不一样的接口，这时候，理所当然地就该使用Adapter模式。就是新建一个Adapter类从这个接口派生，并包含一个到真正的具体实现类的链接。一切托付到Adapter类的调用，都转换成具体实现类的接口，并托付给具体实现类来完成。

然而，有时候，新的实现和接口有很大的差异，比如，有些灯在发光之前先需要预热，这个灯就有三个方法，预热、发光、不发光。可是还需要用同一个开关来控制。这时候怎么办呢？
Bridge模式?嘿嘿，还没有到她登场的时候。
这时候，还是可以用Adapter模式来解决，让这个灯的Adapter在发光这个方法中，分别依次调用该灯实现类的预热方法和发光方法就可以了。

可是有时候，这个不是一种灯需要预热，而是一类灯需要预热。也就是说，A灯商、B灯商、C灯商、D灯商都生产两种灯泡，一个是需要预热的，一个是不需要预热的。
想想看，需要多少Adapter来满足这样的需求？
如果之后，突然又出现一种在关灯之后，需要冷却的灯，并且ABCD都有制造这种灯又怎么办？就是说得为ABCD都添加一种Adapter。
如果之后，又出现了E厂商，每种灯泡都制造，那又怎么办？

考察这里的变化，其实这里有两个变化纬度，一个是灯的操作方法，一个是具体厂商。当两重因素一齐变化的时候，只使用一层抽象来应对，当然是不行的。
解决方法，就是再添加一层抽象。把实现类的接口变成两层。一层是控制逻辑，她的实现类中包括需要预热再点亮的逻辑实现，包括需要关灯后再散热的逻辑实现。另一层接口是针对具体厂商。当然她必须包括所有在控制逻辑层需要使用的方法。
现在，当一个变化出现的时候，只需要添加一个类就可以了。这就是Bridge模式。

再强调一次，模式的使用一定要按照需求来安排。虽然Bridge模式很cool，但是如果就只有一个开关，一个灯泡，并且永不更换，那么使用Bridge模式就是典型的烂设计。