Abstract Server

【一】一个简单的设计问题：设计运行在简易台灯中的软件。台灯由一个开关和一盏台灯组成。你可以询问开关是开着还是关着，也可以让灯打开或关闭。
----------------------------------------
请考虑下图：

我们为什么不喜欢这个设计呢？
这个设计违反了两个设计原则：依赖导致原则(DIP)和开放封闭原则(OCP)。
----------------------------------------
DIP的违反：Switch依赖了具体类Light。DIP告诉我们要有限依赖于抽象类。
OCP的违反：不是很明显，但更加切中要害。
----------------------------------------
因为它迫使我们在任何需要Switch的地方都要附带上Light。我们不能容易地扩展Switch去管理除Light外的其他对象。
----------------------------------------
Abstract Server Pattern
----------------------------------------
【二】为了解决这个问题，我们使用了一个简单的设计模式：Abstract Server模式。见下图：

我们在Switch和Light之间引入了一个接口，这样就使得Switch能够控制任何实现了这个接口的东西。这立即就满足了DIP和OCP。
========================================
【三】谁拥有这个接口？
作为一个有趣的插入语，请注意接口的名字是从它的客户的角度起的。它被称为Switchable而不是ILight。接口属于它的客户，而不是它的派生类。客户和接口之间的逻辑绑定关系。它们之间的关系强到在没有Switchable的情况下就无法使用Switch；但是，在没有Light的情况下却完全可以使用switch。逻辑关系的强度和实体（physical）关系的强度是不一致的。继承是一个比关联强得多的实体关系。

在20世纪90年代初期，我们通常认为实体关系支配着一切。有很多名著都建议把继承层次结构一起放到同一个实体包中。这似乎是合理的，因为继承是一种非常强的实体关系。但是在最近的10年中，我们已经认识到继承的实体强度是一个误导，并且继承层次结构通常也不应该被打包在一起。相反，往往是把客户和它们控制的接口打包在一起。

这种逻辑和实体关系强度的不一致性是静态语言（像C++和Java）的一个产物。动态类型语言（像Smalltalk、Python和Ruby）不具有这种不一致性，因为它们没有用继承去实现多态行为。