正方形不是矩形" << 【OOD设计原则之里氏替换原则（LSP）--- 设计模式之禅读书笔记

【OOD设计原则之里氏替换原则（LSP）】

——"正方形不是矩形"

里氏替换原则（Liskov Substitutiion Principle，LSP）被称作继承复用的基石，它的提出甚至要早于OCP。不过遗憾的是，由于对这一原则的理解各不相同，经过多次的翻译、转述，LSP成了OOD设计原则中争议最多的话题之一。
其实早在1987年的OOPSLA大会上，麻省理工学院（MIT）计算机科学实验室的Liskov女士就发表了经典文章Data Abstraction and Hierarchy，其中提出了以她名字命名的Liskov替换原则（The Liskov Substitution Principle），简称LSP。该原则说明了什么时候该使用继承，什么时候不该使用以及为什么。一年后此文发表在ACM的SIGPLAN
Notices杂志上，更是影响深远。Liskov在这篇文章中写到：
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.
意思是：“类型层次由子类型和超类型（也就是父类）组成，直觉告诉我们，子类型的含义就是该类型的对象提供了另外一个类型（超类型）的对象的所有行为功能，并有所扩充。这里需要如下的替换性质：若对于每一个类型S的对象o1，都存在一个类型T的对象o2，使得在所有针对T编写的程序P中，用o1替换o2后，程序P的行为功能不变，则S是T的子类型。”这就是LSP的最初含义。
而著名技术作家Robert Martin在1996年为《C++ Reporter》写了一篇题为《The The Liskov Substitution Principle》的文章，专门介绍LSP。在Martin的文章中，他给了LSP一个解释：
Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
意思是：“使用指向基类的指针或引用的函数，必须能够在不知道具体派生类对象类型的情况下使用它们。”在2002年，Martin在他出版的《Agile Software Development Principles Patterns and Practices》一书中，又进一步简化为：
Subtypes must be substitutable for their base types。子类必须能替换成它们的父类。
也是正是由于这许多版本的存在在加上翻译，转述等等问题，最终导致了LSP的多种理解（不深究了）。按照我的理解，上面Liskov的表述虽然拗口，但是也不难明白。再加上Martin的解释，LSP原则就很清楚了。
LSP说的其实是在构建类的继承结构的过程中需要遵循的基本原则，什么时候改用，什么时候不能用，避免继承的滥用。LSP和OCP是相关联的，也可以说是OCP的基本保证。试想，如果某个函数使用了指向基类的指针或引用，但是类的设计却违背了LSP原则，那么这个函数就必须了解该基类的所有派生类。这个函数显然违背开放－封闭原则OCP，因为一旦新构建该基类的子类，此函数就需要修改。

我也来说那个经典的”正方形不是矩形“的问题。在数学的世界里，正方形当然是矩形。用OO的数据，正方形和矩形之间是IS-A的关系——这个关系正好是OO初级教程里说的确定继承关系的依据。因此，理所当然的，正方形类然Square应该继承长方形类Rectangle：


public class Rectangle


{


private long width;

private long height;


public void setWidth(long width){

this.width=width;


}

public void setHeight(long height){

this.height=height;

}

public long getWidth(){

return width;

}

public long getHeight(){

return height;

}




};

public class Square : Rectangle
{

public void setWidth(long width){

this.width=width;

this.height=width;

}

public void setHeight(long height){

this.width=width;

this.height=width;

}

};

假设有这么一个函数：

public Rectangle IncreaseHeight(Rectangle r)

{

while(r.getHeight()<r.getWidth()))

{

r.setHeight(r.getHeight()++)

}



return r;

}

如果传递给IncreaseHeight的是一个Rectangle（长宽不同）的对象的话，没问题；如果传递一个Square对象。。。谁都知道会是个什么结果！出现这个问题的原因就是这个继承结构的设计违反了LSP原则：Square类对Height和Weight的处理和Rectangle对Height和Weight的处理逻辑不同，Rectangle单独改变Widtht和Height，而Square必须同时改变Width和Height。所以，Square和Rectangle之间的继承关系是不能成立的。可以增加一个抽象类Quadrangle，定义四边形的公共方法，Square和Rectangle都从Quadrangle继承这些方法，同时可以添加自己特有的方法：



其实，不只是这个“经典”的问题反映了现实世界中概念和OO概念的区别，很多情况都需要在做OOD的时候仔细考虑。只有符合了LSP的规定，才可能实现OCP。以下几条可作为实践经验：

1.从抽象类继承，不要从实体类继承。因为实体类会具有和特定实体相关的方法，这些方法在子类中可能不会有用。

2.使用契约式编程方法。DBC（Design by Contract）把类和其客户之间的关系看作是一个正式的协议，明确各方的权利和义务。在父类里定义好子类需要实现的功能，而子类只要实现这些功能即可。
3.所有派生类的行为功能必须和客户程序对其基类所期望的保持一致。上面的例子就是违背了这一条。其实，这是OO在继承和重写时的基本要求。