上面的代码中，父类对于 hello 方法的定义是只能扔出空指针异常，但子类覆盖父类的方法时，却扔出了其他异常，违背了父类的约定。那么当父类出现的地方，换成了子类，那么必然会出错。
其实这个例子举得不是很好，因为这个在编译层面可能就有错误。但表达的意思应该是到位了。
而这里的父类的约定，不仅仅指的是语法层面上的约定，还包括实现上的约定。有时候父类会在类注释、方法注释里做了相关约定的说明，当你要覆写父类的方法时，需要弄懂这些约定，否则可能会出现问题。例如子类违背父类声明要实现的功能。比如父类某个排序方法是从小到大来排序，你子类的方法竟然写成了从大到小来排序。
里氏替换原则 LSP 重点强调：对使用者来说，能够使用父类的地方，一定可以使用其子类，并且预期结果是一致的。
接口隔离原则（ISP）接口隔离原则（Interface Segregation Principle）的定义是：类间的依赖关系应该建立在最小的接口上。简单地说：接口的内容一定要尽可能地小，能有多小就多小。
举个例子来说，我们经常会给别人提供服务，而服务调用方可能有很多个。很多时候我们会提供一个统一的接口给不同的调用方，但有些时候调用方 A 只使用 1、2、3 这三个方法，其他方法根本不用。调用方 B 只使用 4、5 两个方法，其他都不用。接口隔离原则的意思是，你应该把 1、2、3 抽离出来作为一个接口，4、5 抽离出来作为一个接口，这样接口之间就隔离开来了。
那么为什么要这么做呢？我想这是为了隔离变化吧！ 想想看，如果我们把 1、2、3、4、5 放在一起，那么当我们修改了 A 调用方才用到 的 1 方法，此时虽然 B 调用方根本没用到 1 方法，但是调用方 B 也会有发生问题的风险。而如果我们把 1、2、3 和 4、5 隔离成两个接口了，我修改 1 方法，绝对不会影响到 4、5 方法。
除了改动导致的变化风险之外，其实还会有其他问题，例如：调用方 A 抱怨，为什么我只用 1、2、3 方法，你还要写上 4、5 方法，增加我的理解成本。调用方 B 同样会有这样的困惑。
在软件设计中，ISP 提倡不要将一个大而全的接口扔给使用者，而是将每个使用者关注的接口进行隔离。
依赖倒置原则（DIP）依赖倒置原则（Dependence Inversion Principle）的定义是：高层模块不应该依赖底层模块，两者都应该依赖其抽象。抽象不应该依赖细节，即接口或抽象类不依赖于实现类。细节应该依赖抽象，即实现类不应该依赖于接口或抽象类。简单地说，就是说我们应该面向接口编程。通过抽象成接口，使各个类的实现彼此独立，实现类之间的松耦合。
如果我们每个人都能通过接口编程，那么我们只需要约定好接口定义，我们就可以很好地合作了。软件设计的 DIP 提倡使用者依赖一个抽象的服务接口，而不是去依赖一个具体的服务执行者，从依赖具体实现转向到依赖抽象接口，倒置过来。
SOLID 原则的本质我们总算把 SOLID 原则中的五个原则说完了。但说了这么一通，好像是懂了，但是好像什么都没记住。 那么我们就来盘一盘他们之间的关系。ThoughtWorks 上有一篇文章说得挺不错，它说：
单一职责是所有设计原则的基础，开闭原则是设计的终极目标。
里氏替换原则强调的是子类替换父类后程序运行时的正确性，它用来帮助实现开闭原则。
而接口隔离原则用来帮助实现里氏替换原则，同时它也体现了单一职责。
依赖倒置原则是过程式编程与面向对象编程的分水岭，同时它也被用来指导接口隔离原则。
简单地说：依赖倒置原则告诉我们要面向接口编程。当我们面向接口编程之后，接口隔离原则和单一职责原则又告诉我们要注意职责的划分，不要什么东西都塞在一起。当我们职责捋得差不多的时候，里氏替换原则告诉我们在使用继承的时候，要注意遵守父类的约定。而上面说的这四个原则，它们的最终目标都是为了实现开闭原则。
参考资料写了这么多年代码，你真的了解SOLID吗？ - 知乎
如何理解 SOLID 原则？ - ThoughtWorks 洞见
重构的七宗罪 - ThoughtWorks 洞见