设计模式初探（3）里氏替换原则

依据开闭原则编写程序，我们根据变化原因的不同将程序分割成了不同的模块，然后拼装在一起。详情请见设计模式初探（2）开闭原则

这个和组装一台电脑类似。主板上需要连接CPU、内存、显卡、硬盘等。我们首先定义好这些硬件和主板连接的接口，对应类型的硬件只需要实现这些接口，就可以和主板连在一起。

但是，连在一起就可以让这台电脑正常运行起来了吗？我们需要一些约定。

里氏替换原则

子类型必须能够替换掉它们的基类型。

也就是说，一个硬件虽然实现了显卡和主板对接所需要的接口，但是想要这个硬件能够正常工作，这个硬件也必须是一个类似显卡的硬件，能够完成图像处理的工作。

落实到程序上来就是：具体类在实现接口时要基于契约。抽象基类的所有具体子类在实现相应接口的时候需要满足同样的前置条件和后置条件。

在编写代码时，我们很可能无意中违反契约。我曾经就在编码中遇到过：

我想封装一个弹窗的组件。它的作用是接收一个UI类的对象作为参数，然后将这个UI居中显示。

代码示例

Alert类将UI类的对象添加进来，然后调整一下位置，逻辑很简单。

其实这里隐含了一个契约，就是UI类的对象在被添加到Alert中之后，它的形状大小不能改变，不然居中就会出现错误。不幸的是，之后我需要实现一个UI类的居中，而这个UI类会随着用户的操作，它的大小可能会发生变化，需要在大小改变后重新进行居中。

为此，我实现了一个UiDynamic类，可以让Alert类订阅它的大小变化事件，重新定位。

代码示例

将UiDynamic的实例传递给Alert类，Alert类必须判断Ui类的类型。需要对Alert类进行修改。

代码示例

很显然，我们不可能在Alert类为每一个特殊的Ui类做一次处理，这样不仅增加了Alert类的复杂度，而且我们不是说好了要对扩展开放，对修改闭合吗？不能每增加一个Ui类就要修改一次Alert类的代码吧~

这样的问题如何解决呢？

可以考虑定制一个AlertDynamic类，专门来处理UiDynamic类~

代码示例