软件设计最大的难题就是应对需求的变化，但是纷繁复杂的需求变化又是不可预料的，我们要为不可预料的变化做好准备，这本身是一件非常痛苦的事情，但好在有大师们已经给我们提出了非常好的六大设计原则和 23 种设计模式来“封装”未来的变化。
在软件设计上有一些经典的设计原则，其中包括，SOLID、KISS、YAGNI、DRY、LOD 等。这些设计原则，从字面上理解，都不难。你一看就感觉懂了，一看就感觉掌握了，但是用在项目中的时候就会发现，“看懂”和“会用”是两回事，而“用好”更是难上加难。我有时会对这些原则理解的不够透彻，导致在使用时过于教条注意，拿原则当真理，生搬硬套，适得其反。
下面我对这些原则做一些梳理和整理，确保自己理解的是正确的。
SOLID 原则并非单纯的 1 个原则，而是由 5 个设计原则组成的，它们分别是：
- 单一职责原则
- 开闭原则
- 里氏替换原则
- 接口隔离原则
- 依赖反转原则
分别对应 SOLID 的 S、O、L、I、D 这 5 个英文字母。
原则描述
整体上来讲，这个设计原则是比较简单、容易理解和掌握的。这个原则从定义上是和多态有点类似，但不相同。
里氏替换原则的英文翻译是 Liskov Substitution Principle，缩写为 LSP。
1 | 子类对象（object of subtype/derived class）能够替换程序（program）中父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。 |
里氏替换原则和多态是类似的，有父类出现的地方，那么该地方就可以使用该父类的子类替换。
但这两者的关注角度是不一样的，多态是面向对象变成的一大特性，也是面向对象变成语言的一种语法，是一种代码实现的思路。而里氏替换是一种设计原则，是用于指导继承关系中子类设计该如何设计的，子类的设计要保证在替换弗雷的时候，不改变原有程序的逻辑以及不破坏原有程序的正确性。
如果上面还没理解的话，实际上里氏替换原则还有另外一个更接地气的描述，就是按照协议来设计。
子类在设计的时候，要遵守父类的行为约定（或者叫协议）。父类定义了函数的行为约定，那子类可以改变函数的内部实现逻辑，但不能改变函数原有的行为约定。这里的行为约定包括：函数声明要实现的功能；对输入、输出、异常的约定；甚至包括注释中所罗列的任何特殊说明。
实际上定义中父类和子类孩子间的关系也可以替换成借口和实现类之间的关系。
下面我举几个违反里氏替换原则的例子：
- 子类违背父类生命要实现的功能
父类中提供的 sortOrdersByAmount() 订单排序函数，是按照金额从小到大来给订单排序的，而子类重写这个 sortOrdersByAmount() 订单排序函数之后，是按照创建日期来给订单排序的。那子类的设计就违背里式替换原则。
- 子类违背父类对输入、输出、异常的约定
在父类中，某个函数约定：运行出错的时候返回 null；获取数据为空的时候返回空集合（empty collection）。而子类重载函数之后，实现变了，运行出错返回异常（exception），获取不到数据返回 null。那子类的设计就违背里式替换原则。
在父类中，某个函数约定，输入数据可以是任意整数，但子类实现的时候，只允许输入数据是正整数，负数就抛出，也就是说，子类对输入的数据的校验比父类更加严格，那子类的设计就违背了里式替换原则。
在父类中，某个函数约定，只会抛出 ArgumentNullException 异常，那子类的设计实现中只允许抛出 ArgumentNullException 异常，任何其他异常的抛出，都会导致子类违背里式替换原则。
实际上，里氏替换这个原则是非常宽松的。一般来说，我们写的代码都不会违背它。