敏捷软件开发:原则、模式与实践——第10章 LSP:Liskov替换原则

第10章 LSP:Liskov替换原则   

  Liskov替换原则:子类型(subtype)必须能够替换掉它们的基类型(base type)。

10.1 违反LSP的情形

10.1.1 简单例子

  对LSP的违反导致了OCP的违反:

struct Point { double x, y;}
public enum ShapeType { square, circle };
public class Shape
{
private ShapeType type;
public Shape(ShapeType t) { type = t; }
public static void DrawShape(Shape s)
{
if (s.type == ShapeType.square)
(s as Square).Draw();
else if (s.type == ShapeType.circle)
(s as Circle).Draw();
}
}
public class Circle : Shape
{
private Point center;
private double radius;
public Circle() : base(ShapeType.circle) { }
public void Draw() {/* draws the circle */}
}
public class Square : Shape
{
private Point topLeft;
private double side;
public Square() : base(ShapeType.square) { }
public void Draw() {/* draws the square */}
}

  很显然DrawShape函数违反了OCP。它必须知道Shape类每个可能的派生类,并且每次创建一个Shape类派生出的新类时都必须要更改它。

10.1.2 更微妙的违反情形

  下面是一个Rectangle类型:

public class Rectangle
{
private Point topLeft;
private double width;
private double height;
public double Width
{
get { return width; }
set { width = value; }
}
public double Height
{
get { return height; }
set { height = value; }
}
}

  某一天,用户要求添加正方形的功能。

  我们经常说继承是IS-A(是一个)关系。从一般意义上讲,一个正方形就是一个矩形。因此把Square类视为从Rectangle类派生是合乎逻辑的。不过,这种想法会带来一些微妙但几位值得重视的问题。一般来说,这些问题是很难遇见的,直到我们编写代码时才会发现。

  Square类并不同时需要height和width。但是Square仍会从Rectangle中继承它们。显然这是浪费。假设我们不十分关心内存效率。写出如下自相容的Rectangle类和Square类代码:

public class Rectangle
{
private Point topLeft;
private double width;
private double height;
public virtual double Width
{
get { return width; }
set { width = value; }
}
public virtual double Height
{
get { return height; }
set { height = value; }
}
}
public class Square : Rectangle
{
public override double Width
{
set
{
base.Width = value;
base.Height = value;
}
}
public override double Height
{
set
{
base.Height = value;
base.Width = value;
}
}
}

真正的问题

  现在Square和Rectangle看起来都能够工作。这样看起来该设计似乎是自相容的、正确的。可是,这个结论是错误的。一个自相容的设计未必就和所有的用户程序相容。考虑如下函数:

    void g(Rectangle r)
{
r.Width = ;
r.Height = ;
if (r.Area() != )
throw new Exception("Bad area!");
}

  对于Rectangle来说,此函数运行正确,但是,如果传递进来的是Square对象就会抛出异常。所有,真正的问题是:函数g的编写者假设改变Rectangle的常不会导致宽的改变。

  显然,改变一个长方形的宽不会影响他的长是的假设是合理的!然而,并不是所有作为Rectangle传递的对象都满足这个假设。函数g对于Square、Rectangle层次结构来说是脆弱的。对于g来说,Square不能替换Rectangle,因此Square和Rectangle之间的关系是违反LSP的。

有效性并非本质属性

  一个模型,如果孤立的看,并不具有真正意义上的有效性。模型的有效性只能通过它的客户程序来表现。因此,像其他原则一样,只预测那些最明显的对于LSP的违反的情况而推迟所有其他的预测,直到出现相关的脆弱性的臭味时,才去处理它们。

ISA是关于行为的

  OOD中IS-A关系是就行为方式而言的,行为方式是可以进行合理假设的,是客户程序所依赖的。

10.2 用提取公共部分的方法代替继承

查看如下代码:

public class Line
{
private Point p1;
private Point p2;
public Line(Point p1, Point p2) { this.p1 = p1; this.p2 = p2; }
public Point P1 { get { return p1; } }
public Point P2 { get { return p2; } }
public double Slope { get {/*code*/} }
public double YIntercept { get {/*code*/} }
public virtual bool IsOn(Point p) {/*code*/}
} public class LineSegment : Line
{
public LineSegment(Point p1, Point p2) : base(p1, p2) { }
public double Length() { get {/*code*/} }
public override bool IsOn(Point p) {/*code*/}
}

  初看,会觉得它们之间自然有继承关系。但是,这两个类还是以微妙的方式违反了LSP。

  Line的使用者可以期望和该Line具有线性线性对应关系的所有点都在该Line上。例如,由YIntercept属性返回的点就是线和轴的交点。由于这个点和线具有线性对应关系,所以Line的使用者可以期望IsOn(YIntercept())==true。然而,对于许多LineSegment的实例,这条声明会失效。

  一个简单的方案可以解决Line和LineSegment的问题,该方案也阐明了一个OOD的重要工具。如果我们可以同时具有Line类和LineSegment类的访问权限,那么可以把这两个类的公共部分提出来一个抽象基类。如下:

public abstract class LinearObject
{
private Point p1;
private Point p2;
public LinearObject(Point p1, Point p2)
{ this.p1 = p1; this.p2 = p2; }
public Point P1 { get { return p1; } }
public Point P2 { get { return p2; } }
public double Slope { get {/*code*/} }
public double YIntercept { get {/*code*/} }
public virtual bool IsOn(Point p) {/*code*/}
} public class Line : LinearObject
{
public Line(Point p1, Point p2) : base(p1, p2) { }
public override bool IsOn(Point p) {/*code*/}
} public class LineSegment : LinearObject
{
public LineSegment(Point p1, Point p2) : base(p1, p2) { }
public double GetLength() {/*code*/}
public override bool IsOn(Point p) {/*code*/}
}

  提取公共部分是一个有效的工具。如果两个类中有一些公共的特性,那么很可能稍后出现的其他类也会要这些特性。例如Ray类:

public class Ray : LinearObject
{
public Ray(Point p1, Point p2) : base(p1, p2) {/*code*/}
public override bool IsOn(Point p) {/*code*/}
}

10.3 启发式规则和习惯用法

  完成的功能少于基类的派生类通常是不能替换其类的,因此就违反了LSP。

  查看如下代码:

public class Base
{
public virtual void f() {/*some code*/}
}
public class Derived : Base
{
public override void f() { }
}

  在Base中实现了函数f。不过,在Derived中,函数f是退化的。也许,Derived的编程者认为函数f在Derived中没有用处。遗憾的是,Base的使用者不知道他们不应该调用f,因此就出现了一个替换违规。

  在退化类中存在退化函数并不总是表示违反了LSP,但是当存在这种情况时,还是值得注意一下的。

10.4 结论  
  OCP是OOD中很多说法的核心。LSP是使OCP成为可能的主要原因之一。
  术语IS-A的含义过于宽泛以至于不能作为子类型的定义。子类型的正确定义是可替换的。

摘自:《敏捷软件开发:原则、模式与实践(C#版)》Robert C.Martin    Micah Martin 著

转载请注明出处:

作者:JesseLZJ
出处:http://jesselzj.cnblogs.com

上一篇:软件开发学习笔记 <二>软件开发模型、Up、Rup、敏捷Up


下一篇:安卓高级6 SnackBar