-
LSP
(里氏代换原则)
编辑
本词条缺少
名片图,补充相关内容使词条更完整,还能快速升级,赶紧来
编辑吧!
LSP是里氏代换原则的英文Liskov Substitution Principle的缩写,LSP讲的是基类和子类的关系。只有当这种关系存在时,里氏代换关系才存在。
-
中文名
- 里氏代换原则
-
外文名
- Liskov Substitution Principle
目录
Liskov替换原则:子类型必须能够替换它们的基类型
1. 如果每一个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都代换为o2时,程序P的行为没有变化,那么类型T2是类型T1的子类型。
2. 换言之,一个软件实体如果使用的是一个基类的话,那么一定适用于其子类,而且它根本不能察觉出基类对象和子类对象的区别。只有衍生类替换基类的同时软件实体的功能没有发生变化,基类才能真正被复用。
3.
里氏代换原则由Barbar Liskov(芭芭拉.里氏)提出,是继承复用的基石。
4. 一个继承是否符合
里氏代换原则,可以判断该继承是否合理(是否隐藏有缺陷)。
(1) 应当尽量从抽象类继承,而不从具体类继承。
一般而言,如果有两个具体类A、B有继承关系,那么一个最简单的修改方案是建立一个抽象类C,然后让类A和B成为抽象类C的子类。即如果有一个由继承关系形成的
等级结构的话,那么在等级结构的树形图上面所有的树叶节点都应当是具体类,而所有的树枝节点都应当是抽象类或者接口。
1. 为了保持LSP,所有子类必须符合使用基类的client所期望的行为。
2. 一个子类型不得具有比基类型(base type)更多的限制,可能这对于基类型来说是合法的,但是可能会因为违背子类型的其中一个额外限制,从而违背了LSP!
3. LSP保证一个子类总是能够被用在其基类可以出现的地方!
LSP讲的是基类和子类的关系。只有当这种关系存在时,里氏代换关系才存在。如果两个具体的类A,B之间的关系违反了LSP的设计,(假设是从B到A的继承关系)那么根据具体的情况可以在下面的两种重构方案中选择一种。 创建一个新的抽象类C,作为两个具体类的超类,将A,B的共同行为移动到C中来解决问题。 从B到A的继承关系改为委派关系。
在进行设计的时候,我们尽量从抽象类继承,而不是从具体类继承。如果从继承等级树来看,所有
叶子节点应当是具体类,而所有的树枝节点应当是抽象类或者接口。当然这个只是一个一般性的指导原则,使用的时候还要具体情况具体分析。
Composite模式,Proxy模式,Strategy模式
里氏代换原则(Liskov Substitution Principle)
里氏代换原则是由麻省理工学院(MIT)计算机科学实验室的Liskov女士,在1987年的OOPSLA大会上发表的一篇文章《Data Abstraction and Hierarchy》里面提出来的,主要阐述了有关继承的一些原则,也就是什么时候应该使用继承,什么时候不应该使用继承,以及其中的蕴涵的原理。2002年,软件工程大师Robert C. Martin,出版了一本《Agile Software Development Principles Patterns and Practices》,在文中他把
里氏代换原则最终简化为一句话:"Subtypes must be substitutable for their base types",也就是说,子类必须能够替换成它们的基类。
我们把
里氏代换原则解释得更完整一些:在一个软件系统中,子类应该可以替换任何基类能够出现的地方,并且经过替换以后,代码还能正常工作。子类也能够在基类的基础上增加新的行为。
里氏代换原则是对开闭原则的补充,它讲的是基类和子类的关系。只有当这种关系存在时,里氏代换关系才存在。
"正方形是长方形"是一个理解
里氏代换原则的最经典的例子。在数学领域里,正方形毫无疑问是长方形,它是一个长宽相等的长方形。所以,应该让正方形继承自长方形。
长方形类如程序10-1所示。
程序10-1 长方形类Rectangle.java
package principle.liskovsubstitution; public class Rectangle { private int height; private int width; public int getHeight() { return height; } public void setHeight(int height) { this.height = height; } public int getWidth() { return width; } public void setWidth(int width) { this.width = width; } } 继承了长方形的
正方形类如程序10-2所示。
程序10-2 正方形类Square.java
package principle.liskovsubstitution; public class Square extends Rectangle { public void setWidth(int width) { super.setWidth(width); super.setHeight(width); } public void setHeight(int height) { super.setWidth(height); super.setHeight(height); } } 由于
正方形的长度和宽度必须相等,所以在方法setLength()和setWidth()中,对长度和宽度赋值相同。程序10-3所示的测试类中的函数zoom()用来增加长方形的长和宽。
程序10-3 测试类TestRectangle.java
package principle.liskovsubstitution; public class TestRectangle { public void zoom(Rectangle rectangle, int width, int height) { rectangle.setWidth(rectangle.getWidth() + width); rectangle.setHeight(rectangle.getHeight() + height); } } 显然,当增加的长度和宽度不同时,不能够将其中的长方形换成其子类正方形。这就违反了
里氏代换原则。
程序10-4 父类Base.java
package principle.liskovsubstitution; public abstract class Base { private int height; private int width; public int getHeight() { return height; } public void setHeight(int height) { this.height = height; } public int getWidth() { return width; } public void setWidth(int width) { this.width = width; } public abstract void zoom(int width, int height); } 长方形类继承自该父类,并编写自己的zoom()实现函数,如程序10-5所示。
程序10-5 修改后的长方形类BaseRectangle.java
package principle.liskovsubstitution; public class BaseRectangle extends Base { public void zoom(int width, int height) { setWidth(getWidth() + width); setHeight(getHeight() + height); } } 正方形类也继承自该父类,并编写自己的zoom()实现函数,如程序10-6所示。
程序10-6 修改后的正方形类BaseSquare.java
package principle.liskovsubstitution; public class BaseSquare extends Base { public void setWidth(int width) { super.setWidth(width); super.setHeight(width); } public void setHeight(int height) { super.setWidth(height); super.setHeight(height); } public void zoom(int width, int height) { int length = (width + height) /2; setWidth(getWidth() + length); setHeight(getHeight() + length); } } 编写测试函数如程序10-7所示。
程序10-7 修改后的测试类BastTest.java
package principle.liskovsubstitution; public class BastTest { public void zoom(Base base, int width, int height) { base.zoom(width, height); } } 此时的Base类可以被它的子类Rectangle和Square所替代,而不用改变测试代码。这就是符合
里氏代换原则的编写方式。
由此可见,在进行设计的时候,我们尽量从抽象类继承,而不是从具体类继承。如果从继承等级树来看,所有
叶子节点应当是具体类,而所有的树枝节点应当是抽象类或者接口。当然这只是一个一般性的指导原则,使用的时候还要具体情况具体分析。