如果 对每一个 类型为 T1 的 对象 o1 , 都有 类型为 T2 的 对象 o2 ,
里氏替换原则主要阐述了关于面向对象继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中蕴含的原理。里氏替换原是继承复用的基础，它反映了父类与子类之间的关系。
里氏替换原则（Liskov Substitution Principle，LSP）是面向对象编程中的一个基本原则，它指出如果一个类型 A 是另一个类型 B 的子类型，那么在使用类型 B 的代码中，可以用类型 A 的实例替换类型 B 的实例，程序的行为应该保持一致。里氏替换原则是实现面向对象编程的关键之一，能够有效提高代码的可维护性、可扩展性和可复用性。在 Java 编程中，里氏替换原则非常重要，本文将详细介绍 Java 中的里氏替换原则，并给出示例说明。
里氏替换原则（Liskov Substitution Principle，LSP）是面向对象设计（OOD）中比较重要、常见的一种，下面来总结里氏替换原则的知识点，包括：
里氏替换原则告诉我们，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。里氏替换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。
如果对每一个类型为S的对象o1,都有类型为T的对象o2,使得以T定义的所有程序P在所有的对象o1都代换成o2时,程序P的行为没有发生变化,那么类型S是类型T的子类型.
里氏替换原则表示如果对每一个类型为 S 的对象 o1 都有类型为 T 的对象 o2 ，使得以 T 定义的所有程序 P 在所有的对象 o1 都代换成 o2 时 ，程序 P 的行为没有发生变化 ，那么类型 S 是类型 T 的子类型。也就是说，在程序中可以将子类对象替换父类对象，而程序逻辑不变。
子类的行为 要和 父类 保持一致 , 如果无法达到这一点 , 就无法遵守里氏替换原则 ;
尽管大家都认为SOLID是非常重要的设计原则，并且对每一条原则都耳熟能详，但我发现大部分开发者并没有真正理解。要获得最大收益，就必须理解它们之间的关系，并综合应用所有这些原则。只有把SOLID作为一个整体，才可能构建出坚实(Solid)的软件。遗憾的是，我们看到的书籍和文章都在罗列每个原则，没有把它们作为一个整体来看，甚至提出SOLID原则的Bob大叔也没能讲透彻。因此我尝试介绍一下我的理解。
花下猫语：断更 4 个月的“Python工匠”系列终于更新了，这个系列的文章我大多已分享过，这篇当然不会错过。
我们还是来看看相对通俗点儿的定义。 里氏替换原则（Liskov Substitution Principle，LSP）可以解释为：
里氏替换原则（LSP，Liskov Substitution Principle）是关于继承机制的原则，是实现开放封闭原则的具体规范，违反了里氏替换原则必然违反了开放封闭原则。
里氏替换原则(Liskov Substitution Principle，LSP)由麻省理工学院计算机科学实验室的里斯科夫(Liskov)女士在 1987 年的 "面向对象技术的高峰会议(OOPSLA)"上发表的一篇文章《数据抽象和层次》里提出来的，她提出：继承必须确保超类所拥有的性质在子类中仍然成立(Inheritance should ensure that any property proved about supertype objects also holds for subtype objects)。里氏替换原则主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中蕴含的原理。里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对实现抽象化的具体步骤的规范。 根据上述理解，对里氏替换原则的定义可以总结如下： ♞ 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法 ♞ 子类中可以增加自己特有的方法 ♞ 子类的方法重载父类的方法时，方法的前置条件(即方法的输入参数)要比父类的方法更宽松 ♞ 子类的方法实现父类的方法时(重写/重载或实现抽象方法)，方法的后置条件(即方法的的输出/返回值)要比父类的方法更严格或相等
先看看里氏替换原则（Liskov Substitution Principle）的定义：
第一种：If for each object O1 of type S there is an object O2 fo type T such that for all programs P defined in terms of T, the behavior of P is unchanged when O1 is substitueted for O2 then S is a subtype of T. （对于每一个S类型的对象O1， 都有一个T类型的对象O2，使以T定义的程序P在使用O2替换O1时，行为不发生变化，则S是T的子类）。
设计模式原则 之 里氏替换原则（LSP） 有多少小伙伴是不知道里式替换原则的? 我们写了好多年的代码, 天天都在用继承, 子类. 可是, 却不知道里式替换原则? 赶紧来看看吧. 一. 什么是里式替
在面向对象的程序设计中，里氏替换原则（Liskov Substitution principle）是对子类型的特别定义。它由芭芭拉·利斯科夫（Barbara Liskov）在1987年在一次会议上名为“数据的抽象与层次”的演说中首先提出。 里氏替换原则的内容可以描述为： “派生类（子类）对象可以在程序中代替其基类（超类）对象。” 以上内容并非利斯科夫的原文，而是译自罗伯特·马丁（Robert Martin）对原文的解读。 芭芭拉·利斯科夫与周以真（Jeannette Wing）在1994年发表论文并提出以上的Liskov代换原则。
面向对象设计原则是一些通用的软件设计原则，用于指导软件设计人员开发高质量、可扩展、可维护的软件系统。这些原则的作用如下：
里氏替换原则（Liskov Substitution Principle, LSP）是面向对象设计的基本原则之一，由Barbara Liskov提出。这个原则指出，如果类 S 是类 T 的子类型，则程序中使用 T 的对象的地方都可以不经修改地使用 S 的对象。换句话说，子类的对象应该能够替换掉它们的父类对象，而不影响程序的正确性。这个原则强调了继承关系中的行为兼容性，保证了基类和派生类之间的正确抽象和继承关系。
1.继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。
在上面的三块代码中，当调用SmartTest类的resize方法的时候，如果传入的是父类，那么将会可以的，如果传入的是子类，正方形，那么将会不可以的。
里氏替换原则（英文名为Liskov substitution principle，简称LSP）是由Barbara Liskov在1988年提出的，在Robert C. Martin提出的SOLID软件设计原则中的第三个字母L。
里氏替换原则是在做继承设计时需要遵循的原则，不遵循了 LSP 的继承类会带来意想不到的问题。
笔者作为一个菜鸟，会尝试以简单的代码和容易理解的语句去解释这几种原则的特性和应用场景。
衡量软件设计质量的首要标准是该设计是否能满足软件的功能需求。除了功能需求以外，还有很多衡量软件设计质量的标准，包括可读性、可复用性、可扩展性、可维护性等。
▪ 降低代码的灵活性。子类必须拥有父类的属性和方法，让子类自由的世界中多了些约束；
里氏替换原则（LSP），The Liskov Substitution Principle 定义 所有引用基类的地方必须能透明地引用其子类的对象，即子类可以拓展父类的功能，但不能修改父类已有的功能。 也就是说在父类出现的地方子类也可以出现，并且替换为子类也不会报错，引用者根本不需要知道引用的是父类还是子类，但是反过来就行不通了，子类出现的地方父类就不一定能出现并代替子类。 里氏替换原则的特点： 1、子类可以拓展父类的功能，但不能修改父类已有的功能，如果修改了父类已有的功能，可能导致父类定义的功能在子类覆
里氏替换原则（Liskov Substitution Principle , LSP） 由麻省理工学院计算机科学西教授 Barbara Liskov 于1987年提出， 她提出： 继承必须确保超类所拥有的性质在子类中仍然成立。
why(目的):为什么要学习"里式替换原则",我们都知道面向对象的三大特性:封装、继承、多态,该原则就是对良好的"继承关系"定义了一些规范,通过学习理解后可以写出更健壮、更具扩展性的程序；
常用的面向对象设计原则有七个，这七大设计原则都是以可维护性和可复用性为基础的，这些原则并不是孤立存在的，它们相互依赖相互补充，遵循这些设计原则可以有效地提高系统的复用性，同时提高系统的可维护性。
这句话的意思是说，当我们在传递一个父抽象的子类型时，你需要保证你不会修改任何关于这个父抽象的行为和状态语义。
上篇文章说了工厂模式的单例模式和创建模式，单例模式如何在懒加载的情况下保证线程安全性，创建模式通过接口和抽象类，来完成开闭原则。
六原则一法则是指开闭原则、里氏替换原则、依赖倒置原则、单一职责原则、接口隔离原则、合成复用原则、迪米特法则。
里氏替换原则（Liskov Substitution Principle，LSP）是指如果对每一个类型为T1的对象o1，都有类型为T2的对象O2，使得以T1定义的所有程序P在所有的对象O1都替换成O2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。
该文讲述了里氏替换原则，即子类必须能够替换掉父类，并且新添加的功能不能影响到原有的功能。同时，介绍了违反里氏替换原则的危害，以及如何在实际编程中遵循这一原则。
转载自https://www.cnblogs.com/HigginCui/p/6195318.html
随着需求的迭代, 业务越来越复杂, 再修改原有代码, 就很可能引入bug, 需要对整个服务进行测试. 而策略模式就是其中最常用的解决方式.
所以我们需要将其解耦思想为自己所用，从而提升自己编码能力，使自己的代码更加容易维护、扩展。
在学习和使用 ts 的时候，有一个语法会大量的出现，他就是 extends。但是这个语法放到 ts 里，就显得非常怪异，因为好多时候跟我们常规的理解看上去好像不太一样，不就是一个继承吗，咋到处都在乱用啊？
单一职责原则：一个类只做它该做的事情。（单一职责原则想表达的就是”高内聚”，写代码最终极的原则只有六个字”高内聚、低耦合”，就如同葵花宝典或辟邪剑谱的中心思想就八个字”欲练此功必先自宫”，所谓的高内聚就是一个代码模块只完成一项功能，在面向对象中，如果只让一个类完成它该做的事，而不涉及与它无关的领域就是践行了高内聚的原则，这个类就只有单一职责。我们都知道一句话叫”因为专注，所以专业”，一个对象如果承担太多的职责，那么注定它什么都做不好。这个世界上任何好的东西都有两个特征，一个是功能单一，好的相机绝对不是电视购
单一职责原则：一个类只做它该做的事情。（单一职责原则想表达的就是"高内聚"，写代码最终极的原则只有六个字"高内聚、低耦合"，就如同葵花宝典或辟邪剑谱的中心思想就八个字"欲练此功必先自宫"，所谓的高内聚就是一个代码模块只完成一项功能，在面向对象中，如果只让一个类完成它该做的事，而不涉及与它无关的领域就是践行了高内聚的原则，这个类就只有单一职责。我们都知道一句话叫"因为专注，所以专业"，一个对象如果承担太多的职责，那么注定它什么都做不好。这个世界上任何好的东西都有两个特征，一个是功能单一，好的相机绝对不是电视购
如何理解单一职责原则： 例如有一个类里面包含了属性以及属性的 get 与 set 方法和一些操作这个类的诸多属性而完成的相关业务逻辑。此时我们可以将这个类分为两个对象，一个用于管理对象的属性，另一个用于管理对象的业务逻辑。
在场景中，三毛需要什么枪支，就直接new 出一个枪支即可，然后其内通过抽象类获取到对象，然后对齐进行修饰
如果要理解为：一个类只有一个职责，当然也是可以的，简单化嘛。 单一职责的原话解释是这样的：There should never be more than one reason for a class to change. 什么意思？那里，应该，没有，多于，一个，原因，使得，类，去，改变。 啊，咱这蹩脚英语，勉强能翻译啊。
说到 SOLID 原则，相信有过几年工作经验的朋友都有个大概印象，但就是不知道它具体是什么。甚至有些工作了十几年的朋友，它们对 SOLID 原则的理解也停留在表面。今天我们就来聊聊 SOLID 原则以及它们之间的关系。
● 1）单一职责原则 ● 2）接口隔离原则 ● 3）依赖倒转原则 ● 4）里氏替换原则 ● 5）开闭原则 ● 6）迪米特法则 ● 7）合成复用原则
里氏替换原则（Liskov Substitution Principle,LSP）是指，如果对每一个类型为T1的对象t1，都替换为类型为T2的对象t2，使得以T1定义的所有程序P在所有的对象t1都替换成t2时，程序P的行为没有发生变化，那么T2就是T1的子类型。 这个定义看上去比较抽象，我们重新理解一下。可以理解为一个软件实体如果适用于一个父类，那么一定适用于其子类，所有引用父类的地方必须能透明地使用其子类的对象，子类的对象能替换父类的对象，而程序逻辑不变。 根据这个理解，隐身含义为：子类可以扩展父类的功能，但不能改变父类原有的功能。
一个类或模块只负责完成一个独立的功能或任务，就能帮助我们将复杂的系统拆分成独立的组件，使得每个组件都具有清晰的责任和功能。
1. If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T,the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
