里氏替换原则

里氏替换原则 通俗的讲就是：子类型必须能够替换掉它们的基类型。 继承是否合理我们需要用里氏替换原则来判断。是否合理并不是从继承的设计本身看，而是从应用场景的角度看。如果在应用场景中，也就是在程序中，子类可以替换父类，那么继承就是合理的，如果不能替换，那么继承就是不合理的。 通常，子类比父类的契约更严格，都是违反里氏替换原则的。一个类如果不是为了被继承而设计，那么最好不要继承它。粗暴的讲，如果不是抽象类或者接口，最好不要继承它，组合由于继承。 来源： oschina 链接： https://my.oschina.net/u/939952/blog/3164580

里氏替换原则 解决类继承(对象)代码耦合性问题 继承关系中 父类修改 会影响子类 基本介绍 1) 里氏替换原则(Liskov Substitution Principle)在1988年，由麻省理工学院的以为姓里 的女士提出的。 2) 如果对每个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序 P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1 的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象。 3) 在使用继承时，遵循里氏替换原则，在子类中 尽量不要重写父类的方法 4) 里氏替换原则告诉我们，继承实际上让两个类耦合性增强了， 在适当的情况下，可 以通过聚合，组合，依赖 以下代码 违背了里氏替换原则 package com.wf.zhang.Liskov; public class Liskov { public static void main(String[] args) { A a = new A(); System.out.println("11-3=" + a.func1(11, 3)); System.out.println("1-8=" + a.func1(1, 8)); System.out.println("-----------------------"); B b = new B(); /

定义：所有引用基类的地方必须能透明地使用其子类的对象。问题：有一功能P1，由类A来完成。现在需要将功能P1进行扩展，扩展后的功能为P(P由原有功能P1和新功能P2组成)。 功能P由类A的子类B来完成，子类B在完成新功能P2的同时有可能会导致原有功能P1发生故障。解决：当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法， 也尽量不要重载父类A的方法。举个栗子：士兵使用武器进行射击，包括武器的类别和特点的介绍。情况一：士兵使用手枪进行射击，实现结果为：手枪小，便于携带；手枪一次只能发射一颗子弹；手枪开始射击。 1. 新建一个手枪类HandGun，介绍手枪的特点，代码如下： 2. 新建一个士兵类Soldier，包含手枪的相关方法，代码如下： 3. 在类LSPFragment中实现士兵用手枪进行射击，代码如下： 4. 运行后的结果为： 现在我们需要实现士兵使用步枪进行射击，于是我们就要新增步枪类RifleGun，并且要去修改士兵类Soldier。情况二：士兵使用步枪进行射击，实现结果为：步枪长，不益于携带；步枪可以连续射击；步枪开始射击。 1.新建一个步枪类RifleGun，介绍步枪的特点，代码如下： 2. 修改士兵类Soldier，包含手枪和步枪的相关方法，代码如下： 3. 修改类LSPFragment

1 开闭原则 ：对扩展开放，对修改关闭 在程序需要进行扩展的时候，不去修改原有的代码，而是扩展原有的代码，实现热拔插的效果 2 但一职责原则 ：不要存在要让类变更的多个原因 ，也就是每个类应实现单一原则，如若不行，就把类拆分！ 3 里氏替换原则 ： 任何基类可以出现的地方，子类也应可以出现 里氏替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互，子 类不应该随便破坏它。 4， 依赖倒置原则 ：面向接口编程，依赖抽象，而不依赖具体，写代码用到具体类时，尽量不要与具体类交互 与具体类的上层交互， 5 接口隔离原则 ： 每个接口不存在子类用不到却必须实现的方法，如若不然，就应该将接口拆分，使用多个隔离的接口 ，比使用单个接口（多 个接口方法集和到一起）要好！ 6 迪米特法则(最小知道原则) ：一个类对自己依赖的类知道的越少越好，也就是说 无论被依赖得类多么复杂，都应该将方法封装在内部，通过 public 提供给外部。这样当被依赖的类发生变化时，才能最小的影响该类！ 7 合成复用原则 ：原则是尽量使用合成聚合的方式，而不是使用继承 来源： CSDN 作者： 温馨提示······ 链接： https://blog.csdn.net/weixin_45504233/article/details/103190656

背景 本文标题为什么叫小菜学习设计模式，原因是本文内容主要是学习《大话设计模式》时的笔记摘要部分，当然，并不是记录书中小菜的学习过程，这个完全没有意义，而是指本人学习 设计模式的 成长之旅。 真诚的希望自己能够从一名小菜成长为一名大鸟！ 编写的程序应该满足： 1）可维护 2）可扩展 3）可复用 4）够灵活 废话少说，言归正传，设计模式原则之：里氏替换原则 书面理解 里氏替换原则 ：一个软件实体如果使用的是父类的话，那么一定适用与其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。 子类型必须能够替换掉他们的父类型。 只有当子类可以替换其父类，软件单位的功能不受到影响，父类才能真正被调用，而子类也能够在父类的基础上增加新的行为。 由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展，其实也就是对内关闭，对外开放。 里氏替换原则其实是在诠释依赖倒转原则，依赖倒转可以说是面向对象设计的标志，用哪种语言编写程序不重要，如果编写时考虑的是如何针对抽象编程而不是针对具体细节编程，即使程中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，否则就是面向过程化的设计。 个人的理解 里氏替换原则的意义在于面向对象的多态，以前觉得多态就是不同的表现形式，而且一直觉得重写的多态意义不大

里氏替换原则的定义 里氏替换原则（Liskov Substitution Principle，LSP）由麻省理工学院计算机科学实验室的里斯科夫（Liskov）女士在 1987 年的“面向对象技术的高峰会议”（OOPSLA）上发表的一篇文章《数据抽象和层次》（Data Abstraction and Hierarchy）里提出来的，她提出： 继承必须确保超类所拥有的性质在子类中仍然成立（Inheritance should ensure that any property proved about supertype objects also holds for subtype objects）。 里氏替换原则主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中蕴含的原理。里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。 里氏替换原则的作用 里氏替换原则的主要作用如下。 里氏替换原则是实现开闭原则的重要方式之一。 它克服了继承中重写父类造成的可复用性变差的缺点。 它是动作正确性的保证。即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。 里氏替换原则的实现方法 里氏替换原则通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。 也就是说：子类继承父类时

里氏替换原则（Liskov Substitution Principle，LSP）是指：继承必须确保超类所拥有的性质在子类中仍然成立。 通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。 当需要重写父类方法的时候，可以将子类"提升"，两个类共同继承更高层的抽象类或接口。两个类的关系由扩展转为关联。下面举例来说明。 Swallow(燕子)是会飞的鸟，而BrownKiwi(几维鸟)是不会飞的鸟。 假如重写BrownKiwi类的setFlySpeed()方法，将飞行速度speed设置为0，那再调用BrownKiwi对象的getFlyTIme则会得到"除0异常"。 想要避免此类问题有很多方法，里氏替换原则提供了一种解决方案，就是将BrownKiwi提升，并让Swallow和BrownKiwi同时继承更高层的一个类。如下图： 这个例子可能不够典型，缺少一些说服力。我觉得设计模式的原则，只是一种方向性的建议，在实际开发活动中，还是要因地制宜，根据实际情况来进行合理的设计。 来源： https://www.cnblogs.com/asenyang/p/11760265.html

抽象的原则 SOLID 单一职责原则（Single Responsibility Principle, SRP） 开放封闭原则（Open/Closed Principle, OCP） 指对扩展开放，对修改封闭 依赖倒置原则（Dependency Inversion Principle, DIP） 里氏替换原则（Liskov Substitution Principle, LSP） 里氏替换原则是指子类必须能够替换成它们的基类 接口隔离原则（Interface Segregation Principle, ISP） 接口隔离原则是指客户端不应该被迫依赖它们不使用的方法 迪米特法则（Law of Demeter） 指模块不应该了解它所操作的对象的内部情况 ref: https://juejin.im/entry/5a39bf776fb9a0450909a4d0 来源： https://www.cnblogs.com/cutepig/p/11674723.html

在软件开发中，为了提高软件系统的可维护性和可复用性，增加软件的可扩展性和灵活性，程序员经理根据7条原则来开发程序，从而提高软件开发效率、节约软件开发成本和维护成本。 1. 开闭原则（Open Closed Principle, OCP） 软件实体应该对扩展开放，对修改关闭。 这里的软件实体包括以下几个部分： 1) 项目中划分出的模块 2) 类与接口 3) 方法 开闭原则的含义是：当应用的需求改变时，在不修改软件实体的源代码的前提下，可以扩展模块的功能，使其满足新的需求。 1.1 作用 开闭原则是面向对象程序设计的终极目标，它使软件实体拥有一定的适应性和了灵活性的同事具备稳定性和延续性。具体来说，其作用如下： (1) 对软件测试的影响 软件遵守开闭原则的话，软件测试时只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然能够正常原型。 (2) 可以提高代码的可复用性 粒度越小，被复用的可能性就约到；在面对对象的程序设计中，更具原子核抽象编程可以提高代码的可服用性。 (3) 可以提高软件的可维护性 遵守开闭原则的软件，其稳定性高和延续性强，从而抑郁扩展和维护。 1.2 实现方法 可以通过“抽象约束、封装变化”来实现开闭原则，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。 因为抽象灵活性好，实用性广，只要抽象的合理

1.开闭原则（OCP--open close principle） 是面向对象设计中“可复用设计”的基石。 开闭原则中的“开”，指对组件功能的拓展是开放的，当需求发生变动时，能够对原模块进行拓展，使其满足新加进来的需求； 开闭原则中的“闭”，指对原功能代码的改动是封闭禁止的。 因此，实现开闭原则的关键就在于使用“抽象”。把系统的全部可能的行为抽象为一个抽象的底层，这个抽象底层规定了全部详细实现必须提供的方法的特征。而作为系统设计的抽象层，要预见全部可能的拓展，当需要对系统的功能进行拓展时，可以从抽象底层导出一个或多个新的详细实现，能够改变系统的行为。 假如一个系统符合开闭原则，那么它应该具有如下的优点： 1）可复用好。能够在软件开发完毕后，仍然能够对软件进行拓展，添加新的功能，而系统原先的代码不必变动。 2）可维护性好。对于系统原有的组件，不必进行改动，这样保证了原有功能的稳定性 2.单一原则 就一个类而言，它只负责一项职责。这就要求在进行功能划分时，将其划分的更加清楚。 单一职责原则是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中。而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。 注意：单一职责同样也适用于方法。一个方法应该尽可能做好一件事情。如果一个方法处理的事情太多，其颗粒度会变得很粗，不利于重用。 3