设计模式六大原则(2):里氏替换原则

肯定有不少人跟我刚看到这项原则的时候一样,对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年,由麻省理工学院的一位姓里的女士(Barbara Liskov)提出来的。

定义1:如果对每一个类型为 T1的对象 o1,都有类型为 T2 的对象o2,使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时,程序 P 的行为没有发生变化,那么类型 T2 是类型 T1 的子类型。

定义2:所有引用基类的地方必须能透明地使用其子类的对象。

问题由来:有一功能P1,由类A完成。现需要将功能P1进行扩展,扩展后的功能为P,其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成,则子类B在完成新功能P2的同时,有可能会导致原有功能P1发生故障。

解决方案:当使用继承时,遵循里氏替换原则。类B继承类A时,除添加新的方法完成新增功能P2外,尽量不要重写父类A的方法,也尽量不要重载父类A的方法。

         继承包含这样一层含义:父类中凡是已经实现好的方法(相对于抽象方法而言),实际上是在设定一系列的规范和契约,虽然它不强制要求所有的子类必须遵从这些契约,但是如果子类对这些非抽象方法任意修改,就会对整个继承体系造成破坏。而里氏替换原则就是表达了这一层含义。

        继承作为面向对象三大特性之一,在给程序设计带来巨大便利的同时,也带来了弊端。比如使用继承会给程序带来侵入性,程序的可移植性降低,增加了对象间的耦合性,如果一个类被其他的类所继承,则当这个类需要修改时,必须考虑到所有的子类,并且父类修改后,所有涉及到子类的功能都有可能会产生故障。

        举例说明继承的风险,我们需要完成一个两数相减的功能,由类A来负责。

[java] view
plain
 copy

  1. class A{  
  2.     public int func1(int a, int b){  
  3.         return a-b;  
  4.     }  
  5. }  
  6.   
  7. public class Client{  
  8.     public static void main(String[] args){  
  9.         A a = new A();  
  10.         System.out.println("100-50="+a.func1(100, 50));  
  11.         System.out.println("100-80="+a.func1(100, 80));  
  12.     }  
  13. }  

 运行结果:

100-50=50
100-80=20

        后来,我们需要增加一个新的功能:完成两数相加,然后再与100求和,由类B来负责。即类B需要完成两个功能:

  • 两数相减。
  • 两数相加,然后再加100。

        由于类A已经实现了第一个功能,所以类B继承类A后,只需要再完成第二个功能就可以了,代码如下:

[java] view
plain
 copy

  1. class B extends A{  
  2.     public int func1(int a, int b){  
  3.         return a+b;  
  4.     }  
  5.       
  6.     public int func2(int a, int b){  
  7.         return func1(a,b)+100;  
  8.     }  
  9. }  
  10.   
  11. public class Client{  
  12.     public static void main(String[] args){  
  13.         B b = new B();  
  14.         System.out.println("100-50="+b.func1(100, 50));  
  15.         System.out.println("100-80="+b.func1(100, 80));  
  16.         System.out.println("100+20+100="+b.func2(100, 20));  
  17.     }  
  18. }  

类B完成后,运行结果:

100-50=150
100-80=180
100+20+100=220

        我们发现原本运行正常的相减功能发生了错误。原因就是类B在给方法起名时无意中重写了父类的方法,造成所有运行相减功能的代码全部调用了类B重写后的方法,造成原本运行正常的功能出现了错误。在本例中,引用基类A完成的功能,换成子类B之后,发生了异常。在实际编程中,我们常常会通过重写父类的方法来完成新的功能,这样写起来虽然简单,但是整个继承体系的可复用性会比较差,特别是运用多态比较频繁时,程序运行出错的几率非常大。如果非要重写父类的方法,比较通用的做法是:原来的父类和子类都继承一个更通俗的基类,原有的继承关系去掉,采用依赖、聚合,组合等关系代替。

        里氏替换原则通俗的来讲就是:子类可以扩展父类的功能,但不能改变父类原有的功能。它包含以下4层含义:

  • 子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法。
  • 子类中可以增加自己特有的方法。
  • 当子类的方法重载父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松。
  • 当子类的方法实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格。

        看上去很不可思议,因为我们会发现在自己编程中常常会违反里氏替换原则,程序照样跑的好好的。所以大家都会产生这样的疑问,假如我非要不遵循里氏替换原则会有什么后果?

        后果就是:你写的代码出问题的几率将会大大增加。

时间: 2024-10-21 02:20:33

设计模式六大原则(2):里氏替换原则的相关文章

深入理解JavaScript系列(8) S.O.L.I.D五大原则之里氏替换原则LSP_javascript技巧

前言 本章我们要讲解的是S.O.L.I.D五大原则JavaScript语言实现的第3篇,里氏替换原则LSP(The Liskov Substitution Principle ). 英文原文:http://freshbrewedcode.com/derekgreer/2011/12/31/solid-javascript-the-liskov-substitution-principle/ 复制代码 开闭原则的描述是: Subtypes must be substitutable for the

举例解析Java的设计模式编程中里氏替换原则的意义_java

里氏替换原则,OCP作为OO的高层原则,主张使用"抽象(Abstraction)"和"多态(Polymorphism)"将设计中的静态结构改为动态结构,维持设计的封闭性."抽象"是语言提供的功能."多态"由继承语义实现. 里氏替换原则包含以下4层含义: 子类可以实现父类的抽象方法,但是不能覆盖父类的非抽象方法. 子类中可以增加自己特有的方法. 当子类覆盖或实现父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更

[OOD]违反里氏替换原则的解决方案

关于OOD中的里氏替换原则,大家耳熟能祥了,不再展开,可以参考设计模式的六大设计原则之里氏替换原则.这里尝试讨论常常违反的两种形式和解决方案. 违反里氏替换原则的根源是对子类及父类关系不明确.我们在设计继承关系常常受一些主观认识的左右,比如Robert C. Martin提到的线段与线的关系,以及被大家说到烂的正方形与矩形.从以前的经验我们认为它们符合继承关系,比如线段是线的较短形式,正方形是矩形的一个特例.但事实上它们并不能完全的包容和替代. 以集合的形式表示,左图是里氏替换的目标,子类可以完

设计模式六大原则 里氏替换原则

设计模式六大原则(2):里氏替换原则 是不是有不少人跟我刚看到这项原则的时候一样,对这个原则的名字充满疑惑其实原因就是这项原则最早是在1988年,由麻省理工学院的一位姓里的女士(Barbara Liskov)提出来的. 2002年,软件工程大师Robert C. Martin,出版了一本<Agile Software Development Principles Patterns and Practices>,在文中他把里氏代换原则最终简化为一句话: "Subtypes must b

设计模式六大原则——里氏替换原则(LSP)

       概述        里氏替换原则(LSP,Liskov Substitution Principle)是关于继承机制的原则,是实现开放封闭原则的具体规范,违反了里氏替换原则必然违反了开放封闭原则.        引经据典                        约瑟夫.斯大林,苏联时期苏联共产党的最高领导人,对于斯大林有没有替身?有几个替身?有一种说法:斯大林有好几个替身,最著名的当属"第一替身"叶夫谢伊.卢比茨基--他"扮演"领袖斯大林长达15

设计模式之禅之六大设计原则-里氏替换原则

里氏替换原则说的就是面向对象语言的继承--->代码共享,减少创建类的工作量,每个子类都拥有父类的方法和属性.--->提高代码的重用性.--->子类可以形似父类,但又特殊于父类.--->提高代码的可扩展性.实现父类的方法,可以为所欲为.许多开源框架的接口都是继承父类完成的.--->提高产品或项目的开放性.--->继承是侵入性的.子类必须拥有父类的属性和方法.让子类自由的世界中多了些约束.--->增强了耦合性.当父类的常量,变量和方法被修改时,需要考虑子类的修改.造成

设计模式学习:里氏替换原则

这节中我们会聊聊里氏替换原则,聊它之前,我们先看看定义. 定义:如果对每一个类型为T1的对象 o1,都有类型为 T2 的对象o2,使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时,程序 P 的行为没有发生变化,那么类型 T2 是类型 T1 的子类型.(摘自java与模式一书) 如果你觉得定义说的模糊了点,不太清楚,没关系,我们慢慢说明白.里氏替换原则的另一个简短的定义是"所有引用基类的地方必须能透明地使用其子类的对象".这个可能更清楚点.如果你熟悉的掌握一门面向对

java设计模式六大原则之场景应用分析

看了一篇文章,感觉收获蛮大,不过还有一些不懂,收藏慢慢研究. 面对项目中如此众多的设计模式,我们有时候无法下手.在强大的设计框架也终脱离不了23种设计模式,6大原则.我们只要把内功修炼好,掌握其精髓也离我们不远了...     目录: 设计模式六大原则(1):单一职责原则 设计模式六大原则(2):里氏替换原则 设计模式六大原则(3):依赖倒置原则 设计模式六大原则(4):接口隔离原则 设计模式六大原则(5):迪米特法则 设计模式六大原则(6):开闭原则 设计模式六大原则(1):单一职责原则 设计

PHP设计模式——六大原则

      声明:本系列博客参考资料<大话设计模式>,作者程杰.      一般认为遵从以下六大原则的代码是易扩展可复用的代码:                                        这六大原则任何面向对象的语言都应该遵守的,要想让你的代码易扩展高服用就尽量去满足这六大原则吧,不一定严格按照某种设计模式,但是如果你的代码符合这六大原则,那么你的代码就是好代码了,好的代码不一定是严格按照设计模式写的代码.          1.单一职责         定义:不要存在多于