里氏替换原则究竟如何理解？

介绍里氏替换原则的文章非常多，但可能大家看完之后，心中仍然留有疑问，如何去落地实现，如何判断是否影响程序功能。本文将带领大家深入理解里氏替换，一起领略下它的真正面目。但在此之前，有必要阐述一下，为什么会提出设计原则以及设计原则的作用。

什么是设计原则设计原则是指导代码设计的经验沉淀，其目的是为了提高软件开发的可维护性。我们知道，程序世界并非一尘不染的，随着业务的发展，之前所设计的流程，会为了适应业务而不断调整改变。 对于开发来说，需要有业务前瞻性，凡事多往前考虑一步，尽量减少因为未来业务改变，而造成系统大范围的改动。一旦大范围改动，势必造成开发和回归的成本。所以开发的时候，多思考这样的设计是否违背了某些原则，如果能尽量向上述的设计原则靠拢，就能达到可维护性的目的。常用的有以下设计原则，后续会逐步推出系列文章，一一讲解

• SOLID原则
  
  
  
  • SRP 单一职责原则
    
  • OCP 开闭原则
    
  • LSP 里式替换原则
    
  • ISP 接口隔离原则
    
  • DIP 依赖倒置原则
    
  
  
• DRY 原则
  
• KISS 原则
  
• YAGNI 原则
  
• LOD 法则
  

 
 
我们来正式讨论本文主角，里氏替换原则。里氏替换原则的定义是
调用父类的地方，可以替换成调用子类，但是不会导致程序出错
这里核心的点在于，替换之后，程序不会出错。即不能导致程序逻辑错误，运行错误。
以我的理解，里氏替换原则对于代码设计的约束可以分为两个角度进行讨论，方法结构的约束和方法逻辑约束。下面我们逐个深入讨论
 
1. 方法结构的约束（方法定义）

1.1 输入参数不能比父类严格

即入参只能是父类入参或者父类入参的父类。即如果父类方法的入参是 P 类，那么子类方法的入参只能是 P 类，或者 P 类的父类。 
 
我们举例说明一下。 下面的例子中， 我们定义了三个类， A，B， C。 其中 B 和 C 是 A 的子类。B 类的入参是P，比父类的宽松，满足法则。而 C 类的入参是 P2，比父类的严格，不满足法则。
之所以这样做，是为了避免子类使用了更加宽松的入参类型中，特有的一些方法，而导致程序出错。
比如下面的例子中，调用了 A 类的 test 方法，并且入参是 P 类。接着用 C 类替换 A 类的位置，同样执行 test 方法，入参还是 P，但是执行会报错（先不考虑编译问题，假设传参能够成功），因为 C 类的 test 方法中，调用了 p2Method 方法，
而这个方案是 P 的子类 P2 的独有方法。

1. class P {
2.     private void method(){};
3. }
5. class P1 extend P {
6. }
8. class P2 extend P1{
9.     private void p2Method(){};
10. }
12. class A {
13.     private void test(P1 p){};
14. }
16. // 符合
17. class B extend A {
18.     private void test(P p){};
19. }
21. // 不符合
22. class C extend A {
23.     private void test(P2 p){
24.         p.p2Method();
25.     };
26. }
29. P p = new P();
31. A a = new A();
32. a.test(p);
34. C c = new C();
35. // 执行失败，因为 P 没有 p2Method 方法。如果用c替换掉a，则会失败
36. c.test(p);

复制代码

 
1.2 返回值不能比父类宽松

 
即返回值只能是父类返回值，或者父类返回值的子类。 
下面的例子中，父类A的返回值是 R1， B的返回值类型是 R2， 满足规则。而 C 的返回值是 R，不满足规则。 之所以要这样做，是因为如果子类返回的类型更加宽松，会导致调用方调用出错。
比如下面的例子中 A 执行了 test方法，返回值是 R1，此时调用 r1Method 是合法的。而如果用 C 类替换掉 A类的位置，因为 C 的test 方法返回是 R，没有r1Method方法，所以调用会出错。（先忽略编译失败的问题）

1. [/code][code]class R {
2.     private void method(){};
3. }
5. class R1 extend R {
6.     private void r1Method(){};
7. }
9. class R2 extend R1{
10.     private void r2Method(){};
11. }
13. class A {
14.     private R1 test(){
15.         ...
16.     };
17. }
19. // 符合
20. class B extend A {
21.     private R2 test(){
22.         ...
23.     };
24. }
26. // 不符合
27. class C extend A {
28.     private R test(){
29.         ...
30.     };
31. }
34. A a = new A();
35. R1 r = a.test();
36. r.r1Method();
38. C c = new C();
39. R1 r = c.test(p);
40. // 执行失败，因为 c.test 的返回值实际上是 R 类，没有 r1Method 方法
41. r.r1Method();

复制代码

 
实际上，方法定义上是否满足里氏替换法则，对于静态语言，编译器会做方法定义的合法性校验。更为重要的在于逻辑上是否满足里氏替换原则，这点需要开发人员自己把控， 也更加重要

 

2. 方法的逻辑

除了在方法定义，在代码逻辑实现的时候，也需要遵循一些约束。做到代码通过了编译校验的同时，在运行中也不会出现意想不到的错误情况。
 
2.1 对入参的逻辑处理不能比父类严格

 
这里的逻辑处理指的是条件判断，类型转换等等。
下面用两个例子来说明。第一个例子是关于类型转换的逻辑。这里有三个参数类，P，P1，P2，其中 P1 和 P2 是 P 的子类。 
A 类提供了 test 方法，并且接收的 入参是 P 类。B 类继承自 A 类，所不同的是， B 类重新实现了 test 方法。 
我们注意到， B 的 test 方法中，对入参 P 类进行了强转，虽然是符合语法约束的，但在某些场景下会出现问题。比如在调用 B 类的 test 方法时，传了 P2，那么强转就会失败了。

1. class P {
2.     private void method(){...};
3. }
5. class P1 extend P {
6.     private void p1Method(){...};
7. }
9. class P2 extend P {
10.     private void p2Method(){...};
11. }
13. class A {
14.     private void test(P p){...};
15. }
17. class B extend A {
18. private void test(P p){    // 这里做了强制转换    P1 p = (P1)p;
19.     p.p1Method();
20. };
21. }
24. // 这样处理没问题
25. P p = new P1();
26. A a = new B();
27. a.test(P1);
29. // 但如果入参是 P2，就会报错了。因为B类中，会将入参强制转换成 P1，类型转换失败
30. P p = new P2();
31. A a = new B();
32. a.test(P1);

复制代码

  
这个例子并非属于极端例子，如果翻看一下实际的应用代码，我相信比比皆是。 那对于这种场景，我们应该怎样去做调整呢？
本质的问题在于，为什么要在代码逻辑中，转成具体的子类 P1 去操作？ 因为要使用 P1 的独有方法。 对此我们可以倒推，原本父类定义中的接口入参类型已经满足不了我们的需求。
解决的方法是，考虑重新对父类的入参进行抽象，将子类的 P1 独有方法沉淀进 P 类。第二个例子是关于条件判断的，子类不能比父类严格。B 类重新实现了 test 方法，并且对于入参的前置条件判断，

由原来的 i