《敏捷软件开发-原则、模式与实践》-第十章 Liskov替换原则（LSP）

LSP就是：子类型必须能够替换掉它们的基类型。

接下来文中举了一个违反LSP的例子并指出违反LSP也会潜在的违反OCP。

有三个类，shape,circle,square。其中shape是父类。circle和square都有draw方法。shape中有drawShape（）方法，在这个方法中通过判断传入的是circle还是square来调用不同的draw方法。而这么设计是因为工程师觉得多态的开销太大了。但是这明显违反了LSP，并且drawShape()方法也违反了OCP，因为如果有新的派生类，这个方法就要被改变。

    接着书中有举了正方形和长方形的例子，大意就是正方形的长宽要保持一致，长方形的长宽可以独立变化，这样令正方形为长方形的子类而导致的一系列问题。当我们setWidth（3），setHeight(4)，assert(area() = 12)的时候，传入子类正方形就会出错。我们在判断两者是否是IS-A的关系的时候，是就他们的行为方式而言的，对象的行为方式才是软件真正需要关注的东西。在最后的总结出，有一句话说的很好：最好的方法是只预测那些最明显的对于LSP的违反情况而推迟所有其他的预测，直到出现相关的脆弱性的时候，才去处理他们。这个观点在前两章都有提到过，算是一个核心观点了。我们目前所学的这些原则，在设计的时候，将最明显的那些东西进行抽象，按照规则去设计，但是不能做过多的设计，否则会造成不必要的复杂性，在出问题的时候再来处理是比较明智的。

    接下来作者介绍了指定契约，个人感觉没啥软用，一般很少会这么搞吧，就不做总结了。

    当我们在实践中遇到LSP的问题时，可以用提取公共部分的方式去代替继承来实现LSP。举个栗子：当我们有“线段“和“线”这两个类的时候，我们可能会设计“线段”继承“线”，但是如果“线”有一个函数，判断“线”与y轴或x轴的交点是否满足某些条件时，“线段”这个子类就不能代替父类，会造成异常，因为线段与坐标轴可能没有交点。我们可以将“线”与“线段”相同性质的部分提取出来作为父类。可以预见到的好处就是，当我们还需要创建一个“镭射线”时，依然可以继承这个父类。

    文中有一段话是对上面的一个比较好的总结，如下：

    如果一组类都支持一个公共的职责，那么它们应该从一个公共的超类继承该职责。如果公共的超类还不存在，那么就创建一个，并把公共的职责放入其中。毕竟，这样一个类的有用性是确定无疑的---你已经展示了一些类会继承这些职责。然后稍后对系统的扩展也许会加入一个新的子类，该子类很可能会以新的方式来支持同样的职责。此时，这个新创建的超类可能会是一个抽象类。

    注意：当设计中出现了一下情况的时候，需要注意是否满足LSP：1、派生类中出现退化函数（即在父类中该方法有用，而子类中重写这个方法且不实现任何功能）2、派生类中抛出异常但是父类没有抛出。

    最后，我们发现，LSP是OCP成为可能的主要原则之一，正是子类型的可替换性才使得基类类型在无需修改的情况下就可以扩展。两个原则是相辅相成的关系。