转:OOD设计原则之里氏替换原则

里氏替换原则（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逻辑不同，Rectangle单独改变Widtht和Height，而Square必须同时改变Width和Height。所以，Square和Rectangle之间的继承关系是不能成立的。可以增加一个抽象类Quadrangle，定义四边形的公共方法，Square和Rectangle都从Quadrangle继承这些方法，同时可以添加自己特有的方法：

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

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

2.使用契约式编程方法。DBC（Design by Contract）把类和其客户之间的关系看作是一个正式的协议，明确各方的权利和义务。在父类里定义好子类需要实现的功能，而子类只要实现这些功能即可。

3.所有派生类的行为功能必须和客户程序对其基类所期望的保持一致。上面的例子就是违背了这一条。其实，这是OO在继承和重写时的基本要求。

转自:http://blog.csdn.net/brookes/article/details/1896758

另一篇:

Functions that  use pointers or references to baseclasses must be able  to use objects of derived classes without knowing it.

所有引用基类的地方必须能透明地使用其子类的对象。

即：

• 所以使用基类代码的地方，用派生类代码替换后，能够正确的执行动作处理。
• 换句话说，如果派生类替换了基类后，不能够正确执行动作，那么他们的继承关系就应该废除。

换个说法，只有满足以下2个条件的OO设计才可被认为是满足了LSP原则：

• 不应该在代码中出现if/else之类对子类类型进行判断的条件。以下代码就违反了LSP定义。

if(objtypeofClass1){

    dosomething

}elseif(objtypeofClass2){

    dosomethingelse

}

• 子类应当可以替换父类并出现在父类能够出现的任何地方，

或者说如果我们把代码中使用基类的地方用它的子类所代替，代码还能正常工作。

里氏替换原则LSP是使代码符合开闭原则的一个重要保证。同时LSP体现了：

• 类的继承原则：如果一个继承类的对象可能会在基类出现的地方出现运行错误，
• 则该子类不应该从该基类继承，或者说，应该重新设计它们之间的关系。
• 动作正确性保证：从另一个侧面上保证了符合LSP设计原则的类的扩展不会给已有的系统引入新的错误。

类的继承原则：

RobertC.Martin氏在介绍LiskovSubstitutionPrinciple(LSP)的原文里，举了Rectangle和Square的例子。

这里沿用这个例子，但用Java语言对其加以重写，并忽略了某些细节只列出下面的精要

部分来说明里氏替换原则对类的继承上的约束。

//代码：

classRectangle{

    doublewidth;

    doubleheight;

    publicdoublegetHeight(){

        returnheight;

    }

    publicvoidsetHeight(doubleheight){

        this.height=height;

    }

    publicdoublegetWidth(){

        returnwidth;

    }

    publicvoidsetWidth(doublewidth){

        this.width=width;

    }

}

classSquareextendsRectangle{

    publicvoidsetHeight(doubleheight){

        super.setHeight(height);

        super.setWidth(height);

    }

    publicvoidsetWidth(doublewidth){

        super.setHeight(width);

        super.setWidth(width);

    }

}

这里Rectangle是基类，Square从Rectangle继承。

这种继承关系有什么问题吗？

假如已有的系统中存在以下既有的业务逻辑代码：

voidg(Rectangler){

    r.setWidth(5);

    r.setHeight(4);

    if(r.getWidth()*r.getHeight()!=20){

        thrownewRuntimeException();

    }

}

则对应于扩展类Square，在调用既有业务逻辑时：

Rectanglesquare=newSquare();

g(square);

时会抛出一个RuntimeException异常。这显然违反了LSP原则。

动作正确性保证：

因为LSP对子类的约束，所以为已存在的类做扩展构造一个新的子类时，

根据LSP的定义，不会给已有的系统引入新的错误。

DesignbyContract

根据BertrandMeyer氏提出的DesignbyContract（DBC：基于合同的设计）概念的描述，

对于类的一个方法，都有一个前提条件以及一个后续条件，前提条件说明方法接受什么样的参数数据等，

只有前提条件得到满足时，这个方法才能被调用；同时后续条件用来说明这个方法完成时的状态，

如果一个方法的执行会导致这个方法的后续条件不成立，那么这个方法也不应该正常返回。

现在把前提条件以及后续条件应用到继承子类中，子类方法应该满足：

１）前提条件不强于基类．

２）后续条件不弱于基类．

换句话说，通过基类的接口调用一个对象时，用户只知道基类前提条件以及后续条件。

因此继承类不得要求用户提供比基类方法要求的更强的前提条件，

亦即，继承类方法必须接受任何基类方法能接受的任何条件（参数）。

同样，继承类必须顺从基类的所有后续条件，亦即，

继承类方法的行为和输出不得违反由基类建立起来的任何约束，不能让用户对继承类方法的输出感到困惑。

这样，我们就有了基于合同的LSP，基于合同的LSP是LSP的一种强化。

在很多情况下，在设计初期我们类之间的关系不是很明确，

LSP则给了我们一个判断和设计类之间关系的基准：需不需要继承，以及怎样设计继承关系。

总结

LSP:子类必须能够替换基类。

Subtypesmustbesubstitutable fortheirbasetypes.

1.LSP关注的是怎样良好的使用继承.

2.必须要清楚是使用一个Method还是要扩展它，但是绝对不是改变它。

3.LSP清晰的指出，OOD的IS-A关系是就行为方式而言，

   行为方式是可以进行合理假设的，是客户程序所依赖的。

4.LSP让我们得出一个重要的结论：一个模型如果孤立的看，并不具有真正意义的有效性。

   模型的有效性只能通过它的客户程序来表现。必须根据设计的使用者做出的合理假设来审视它。

   而假设是难以预测的，直到设计臭味出现的时候才处理它们。

5.对于LSP的违反也潜在的违反了OC

 最初的Rectangle-square例子:

public class Rectangle

{

    protected int _width;

    protected int _height;

    public int Width

    {

        get { return _width; }

    }


    public int Height

    {

        get { return _height; }

    }


    public virtual void SetWidth(int width)

    {

        _width = width;

    }


    public virtual void SetHeight(int height)

    {

        _height = height;

    }

}


public class Square: Rectangle

{

    public override void SetWidth(int width)

    {

        _width = width;

        _height = width;

    }


    public override void SetHeight(int height)

    {

        _height = height;

        _width = height;

    }

}


[TestFixture]

public class RectangleTests

{

    [Test]

    public void AreaOfRectangle()

    {

        Rectangle r = new Square();


        r.SetWidth(5);

        r.SetHeight(2);


        // Will Fail – r is a square and sets

        // width and height equal to each other.

        Assert.IsEqual(r.Width * r.Height,10);

    }

}