连载:面向对象葵花宝典:思想、技巧与实践(32) - LSP原则

LSP是唯一一个以人名命名的设计原则,而且作者还是一个“女博士” 

=============================================================


LSP,Liskov substitution principle,中文翻译为“里氏替换原则”。

 

这是面向对象原则中唯一一个以人名命名的原则,虽然Liskov在中国的知名度没有UNIX的几位巨匠(Kenneth Thompson、Dennis Ritchie)、GOF四人帮那么响亮,但查一下资料,你会发现其实Liskov也是非常牛的:2008年图灵奖获得者,历史上第一个女性计算机博士学位获得者。其详细资料可以在维基百科上查阅: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是无法知道的。

 

也就是说,调用者和父类之间的联系体现在两方面:函数输入,函数输出。详细如下图:

 

有了这个图之后,如何做到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);

        //如下assert判断为false,断言失败,抛出java.lang.AssertionError
        assert( rectangle.getArea() == 20);
    }
}

上面这个样例同时也给出了一个判断子类是否符合LSP的取巧的方法,即:针对父类的单元测试用例,传入子类是否也能够测试通过。如果测试能够通过,则说明符合LSP原则,否则就说明不符合LSP原则

================================================ 
转载请注明出处:http://blog.csdn.net/yunhua_lee/article/details/26807601
================================================ 

时间: 2024-10-03 05:48:09

连载:面向对象葵花宝典:思想、技巧与实践(32) - LSP原则的相关文章

连载:面向对象葵花宝典:思想、技巧与实践(28) - 设计原则:内聚&耦合

前面通过实例讲解了一个一环扣一环的面向对象的开发流程:用例模型 -> 领域模型 -> 设计模型(类模型 + 动态模型),解答了面向对象如何做的问题.接下来我们就要讲"如何做好面向对象设计"的技巧了 =================================================================== [内聚] 参考维基百科的解释,内聚的含义如下: cohesion refers to the degree to which the eleme

连载:面向对象葵花宝典:思想、技巧与实践(1) - 程序设计思想的发展

史前时代:面向机器 最早的程序设计都是采用机器语言来编写的,直接使用二进制码来表示机器能够识别和执行的指令和数据.简单来说,就是直接编写0和1的序列来代表程序语言.例如:使用0000 代表 加载(LOAD),0001 代表 存储(STORE)等.  机器语言由机器直接执行,速度快,但一个很明显的缺点就是:写起来实在是太困难了,一旦你发现自己写错了,改起来更蛋疼!这样直接导致程序编写效率十分低下,编写程序花费的时间往往是实际运行时间的几十倍或几百倍.  有一个关于机器语言和比尔盖茨的笑话,是说比尔

连载:面向对象葵花宝典:思想、技巧与实践(36) - 设计原则如何用?

经过前面深入的阐述,SOLID的原则我们已经基本上讲清楚了,但如果想熟练的应用SOLID原则,仅仅知道SOLID是什么(what)还不够,我们还需要知道SOLID原则在什么时候和什么场景应用(when或where).   幸运的是,SOLID原则的5个独立原则在实际应用中基本上都是独挡一面,并不会在某个地方需要同时从可选的几个原则中挑选一个最优的原则来应用,这样大大降低了我们应用SOLID原则的难度.   SOLID原则具体的应用场景如下: SRP原则:用于类的设计 当我们想出一个类,或者设计出

013_《Delphi面向对象编程思想》

<Delphi面向对象编程思想> Delphi 教程 系列书籍 (013) <Delphi面向对象编程思想> 网友(邦)整理 EMail: shuaihj@163.com 下载地址: Pdf 作者: 刘艺 [作译者介绍] 丛书名: Borland核心技术丛书 出版社:机械工业出版社 ISBN:7111127722 上架时间:2003-10-10 出版日期:2003 年9月 开本:16开 页码:476 版次:1-1 内容简介 这是一本纯粹讨论dlephi面向对象编程的力作. 本书以精

Silverlight游戏设计:(五)面向对象的思想塑造游戏对象

传说,面向对象的开发模式最初是因为程序员偷懒而不小心诞生的.发展至今,人们从最初的热忠于 讨论某某语言是否足够面向对象到现在开始更广泛的关注面向对象的思想而不是具体内容.面向对象的思 想其实并不深奥,它存在的目的只有一个:让程序开发更贴近我们的现实世界. 还记得猫.猫叫:狗.狗吃东西吗?无数的程序员都喜欢将此类似的情形设计当作面向对象最好的例 子.是的,非常生动且形象:但实际运用中你是否能真正做到举一反三? 回述到游戏设计中,大家是否时常会感觉游戏世界与我们的真实世界如此贴近?游戏中的精灵好比我

java语言学习002_面向对象编程思想

      人类在认识世界时,为了方便自己和智慧提升,很自然的对事物进行了分类.对世界进行了抽象,若把所有各个事物看做对象,纵观所有对象,这些对象具有各自的或共有的特征,并且又有共有的或各自的的能力,这样就可以对具有相同一些特征和一些能力的事物进行了归类.       比如,车,有汽车,火车他们都有哪些属性?                  汽车,特征:长度,颜色,速度,轮胎,载重,平面行走--能力:移动,载东西,--                  火车,特征:长度,颜色,速度,轮胎,载重

求助、面向对象的思想查找字符串中的数字

问题描述 要用面向对象的思想来查找字符串中的数字.实现判断某个字符是否位数字的方法如下:publicstaticboolgetNumeric(stringstr){boolb=false;string[]ArrayInt=newstring[]{"1","2","3","4","5","6","7","8","9","

将面向对象的思想带入TC

写TC貌似是很简单的工作,但当动手写的时候往往会出现,不知道写什么,又感觉有一堆的东西需要写,即使一个简单的日常也会觉得里面的逻辑非常复杂,然后就是晕得不知所向. 个人认为,写TC没有固定的模式,也没有唯一的答案,每个人的方式不同,习惯不同,TC中的如何分类归纳也就自然不相同.但目标是一致的,基本目标是覆盖需求.无盲区:加强目标是加深测试点,完善用户友好性等. 下面分享下我写TC的几种思路. 第一种思路--先对象,后流程 面向对象是在平常入门学习中 首先接触到的概念,它不仅仅存在于代码的编写中,

重温面向对象的思想——构造器和重载

1.this关键字 this表示这个对象的参考名称:例如this.age1=age2;表示将age2的值,赋值给这个对象的私有属性age1. 2. .重温面向对象的思想--构造器和重载 构造器:创建一个对象时,有时候需要对在实例化一个对象时,对这个对象进行初始化,这个时候我们就需要构造方法来进行这种初始化. 重载:当这种初始化需要按照不同的语境,不同的参数的构造器来进行初始化. 总结--方法的重载是多种构造器,用以完成不同的初始化. -注意:构造器==构造方法,两者一样 3.构造方法和自定义方法