第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 著
转载请注明出处：