(32) – LSP原则

最后更新于:2022-04-01 07:29:53

## 连载:面向对象葵花宝典:思想、技巧与实践(32) - LSP原则 LSP是唯一一个以人名命名的设计原则,而且作者还是一个“女博士” ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-01-19_569e21abc5518.gif) ============================================================= **LSP**,Liskov substitution principle,中文翻译为“**里氏替换原则**”。   这是面向对象原则中唯一一个以人名命名的原则,虽然Liskov在中国的知名度没有UNIX的几位巨匠(Kenneth Thompson、Dennis Ritchie)、GOF四人帮那么响亮,但查一下资料,你会发现其实Liskov也是非常牛的:2008年图灵奖获得者,历史上第一个女性计算机博士学位获得者。其详细资料可以在维基百科上查阅:[http://en.wikipedia.org/wiki/Barbara_Liskov](http://en.wikipedia.org/wiki/Barbara_Liskov)    言归正传,我们来看看LSP原则到底是怎么一回事。 LSP最原始的解释当然来源于Liskov女士了,她在1987年的OOPSLA大会上提出了LSP原则,1988年,她将文章发表在ACM的SIGPLAN Notices杂志上,其中详细解释了LSP原则: A type hierarchy is composed of subtypes and supertypes. The intuitive idea of a subtype is one whose objects provide all the behavior of objects of another type (the supertype) plus something extra.What is wanted here is something like the following substitution property: 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. 英文比较长,看起来比较累,我们简单的翻译并归纳一下: 1) **子类的对象提供了父类的所有行为**,且加上子类额外的一些东西(可以是功能,也可以是属性); 2) 当程序基于父类实现时,**如果将子类替换父类而程序不需要修改**,则说明符合LSP原则   虽然我们稍微翻译和整理了一下,但实际上还是很拗口和难以理解。 幸好还有Martin大师也觉得这个不怎么通俗易懂,Robert Martin在1996年为《C++ Reporter》写了一篇题为《The The Liskov Substitution Principle》的文章,解释如下: Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. 翻译一下就是:函数使用指向父类的指针或者引用时,必须能够在不知道子类类型的情况下使用子类的对象。   Martin大师解释了一下,相对容易理解多了。但Martin大师还不满足,在2002年,Martin在他出版的《Agile   Software   Development   Principles   Patterns   and   Practices》一书中,又进一步简化为: Subtypes   must   be   substitutable   for   their   base   types。 翻译一下就是:子类必须能替换成它们的父类。   经过Martin大师的两次翻译,我相信LSP原则本身已经解释得比较容易理解了,但问题的关键是:如何满足LSP原则?或者更通俗的讲:什么情况下子类才能替换父类?   我们知道,对于调用者来说(Liskov解释中提到的P),和父类交互无非就是两部分:调用父类的方法、得到父类方法的输出,中间的处理过程,P是无法知道的。   也就是说,调用者和父类之间的联系体现在两方面:函数输入,函数输出。详细如下图:  ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-01-20_569f5ccb01a50.jpg) 有了这个图之后,如何做到LSP原则就清晰了: 1) **子类必须实现或者继承父类所有的公有函数**,否则调用者调用了一个父类中有的函数,而子类中没有,运行时就会出错; 2) **子类每个函数的输入参数必须和父类一样**,否则调用父类的代码不能调用子类; 3) **子类每个函数的输出**(返回值、修改全局变量、插入数据库、发送网络数据等)必须不比父类少,否则基于父类的输出做的处理就没法完成。   有了这三条原则后,就可以很方便的判断类设计是否符合LSP原则了。需要注意的是第3条的关键是“不比父类少”,也就是说可以比父类多,即:父类的输出是子类输出的子集。   有的朋友看到这三条原则可能有点纳闷:这三条原则一出,那子类还有什么区别哦,岂不都是一样的实现了,那还会有不同的子类么?   其实如果仔细研究这三条原则,就会发现其中**只是约定了输入输出,而并没有约束中间的处理过程**。例如:同样一个写数据库的输出,A类可以是读取XML数据然后写入数据库,B类可以是从其它数据库读取数据然后本地的数据库,C类可以是通过分析业务日志得到数据然后写入数据库。这3个类的处理过程都不一样,但最后都写入数据到数据库了。   LSP原则最经典的例子就是“长方形和正方形”这个例子。从数学的角度来看,正方形是一种特殊的长方形,但从面向对象的角度来观察,正方形并不能作为长方形的一个子类。原因在于对于长方形来说,设定了宽高后,面积 = 宽 * 高;但对于正方形来说,设定高同时就设定了宽,设定宽就同时设定了高,最后的面积并不是等于我们设定的 宽 * 高,而是等于最后一次设定的宽或者高的平方。 具体代码样例如下: Rectangle.java ~~~ package com.oo.java.principles.lsp; /** * 长方形 */ public class Rectangle { protected int _width; protected int _height; /** * 设定宽 * @param width */ public void setWidth(int width){ this._width = width; } /** * 设定高 * @param height */ public void setHeight(int height){ this._height = height; } /** * 获取面积 * @return */ public int getArea(){ return this._width * this._height; } } ~~~ Square.java ~~~ package com.oo.java.principles.lsp; /** * 正方形 */ public class Square extends Rectangle { /** * 设定“宽”,与长方形不同的是:设定了正方形的宽,同时就设定了正方形的高 */ public void setWidth(int width){ this._width = width; this._height = width; } /** * 设定“高”,与长方形不同的是:设定了正方形的高,同时就设定了正方形的宽 */ public void setHeight(int height){ this._width = height; this._height = height; } } ~~~ UnitTester.java ~~~ package com.oo.java.principles.lsp; public class UnitTester { public static void main(String[] args){ Rectangle rectangle = new Rectangle(); rectangle.setWidth(4); rectangle.setHeight(5); //如下assert判断为true assert( rectangle.getArea() == 20); rectangle = new Square(); rectangle.setWidth(4); rectangle.setHeight(5); //<span style="color:#ff0000;">如下assert判断为false,断言失败,抛出java.lang.AssertionError</span> assert( rectangle.getArea() == 20); } } ~~~ 上面这个样例同时也给出了一个判断子类是否符合LSP的取巧的方法,即:针对父类的单元测试用例,传入子类是否也能够测试通过。如果测试能够通过,则说明符合LSP原则,否则就说明不符合LSP原则
';