【设计原则】里氏替换原则（LSP）：构建稳健继承体系的黄金法则

深入理解里氏替换原则（LSP）及其在C#中的实践 一、什么是里氏替换原则？二、为什么需要LSP？三、经典违反案例：矩形与正方形问题四、正确的设计实践方案1：通过接口分离方案2：使用抽象类 五、LSP的关键检查点六、C#中的实现建议七、单元测试验证LSP八、最佳实践总结九、现实应用场景

一、什么是里氏替换原则？

里氏替换原则（Liskov Substitution Principle, LSP）是面向对象设计SOLID原则中的"L"，由Barbara Liskov在1987年提出。其核心定义为：

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

这意味着：

子类必须完全实现父类的抽象方法子类可以扩展父类功能但不能改变原有行为子类方法的前置条件不应强于父类子类方法的后置条件不应弱于父类 二、为什么需要LSP？ 保证继承关系的正确性提高代码的可维护性增强系统的可扩展性降低单元测试的复杂度 三、经典违反案例：矩形与正方形问题 // 基类：矩形 public class Rectangle { // 矩形的宽度属性 public virtual int Width { get; set; } // 矩形的高度属性 public virtual int Height { get; set; } // 计算矩形的面积 public int Area => Width * Height; } // 子类：正方形 public class Square : Rectangle { // 重写Width属性，确保宽度和高度始终相等 public override int Width { set { base.Width = base.Height = value; } } // 重写Height属性，确保高度和宽度始终相等 public override int Height { set { base.Width = base.Height = value; } } } // 使用场景：面积计算器 public class AreaCalculator { // 计算矩形面积的方法 public void Calculate(Rectangle rect) { // 设置宽度为5 rect.Width = 5; // 设置高度为4 rect.Height = 4; // 输出期望面积和实际面积 Console.WriteLine($"期望面积20，实际得到：{rect.Area}"); } } // 调用时会出现问题 new AreaCalculator().Calculate(new Square()); // 输出16而不是20

问题分析： Square改变了Rectangle的基本行为约定，导致父类替换时出现意外结果，违反了LSP。

四、正确的设计实践 方案1：通过接口分离 // 定义形状接口 public interface IShape { // 面积属性 int Area { get; } } // 矩形类实现IShape接口 public class Rectangle : IShape { // 宽度属性 public int Width { get; set; } // 高度属性 public int Height { get; set; } // 计算面积 public int Area => Width * Height; } // 正方形类实现IShape接口 public class Square : IShape { // 边长属性 public int SideLength { get; set; } // 计算面积 public int Area => SideLength * SideLength; } 方案2：使用抽象类 // 定义抽象形状类 public abstract class Shape { // 抽象面积属性 public abstract int Area { get; } } // 矩形类继承Shape public class Rectangle : Shape { // 宽度属性 public int Width { get; set; } // 高度属性 public int Height { get; set; } // 实现面积计算 public override int Area => Width * Height; } // 正方形类继承Shape public class Square : Shape { // 边长属性 public int SideLength { get; set; } // 实现面积计算 public override int Area => SideLength * SideLength; } 五、LSP的关键检查点

方法签名一致性

// 父类：鸟 public class Bird { // 飞的方法 public virtual void Fly() { /*...*/ } } // 违反LSP的子类：企鹅 public class Penguin : Bird { // 重写Fly方法，抛出异常 public override void Fly() { throw new NotSupportedException(); } }

解决方案：建立IFlyable接口

前置条件不强于父类

// 父类 public virtual void SetTemperature(int temp) { // 接受0-100 } // 违反LSP的子类 public override void SetTemperature(int temp) { if(temp < 10) throw new ArgumentException(); // 加强限制 //... }

后置条件不弱于父类

// 父类方法保证返回正数 public virtual int Calculate() { return Math.Abs(result); } // 违反LSP的子类 public override int Calculate() { return result; // 可能返回负数 } 六、C#中的实现建议 使用"override"关键字确保正确重写密封基类方法防止意外修改public class Vehicle { // 密封Start方法，防止子类修改 public sealed override void Start() { /* 基础实现 */ } } 接口默认实现（C#8.0+）public interface IWorker { // 默认实现Work方法 void Work() => Console.WriteLine("Working..."); } 七、单元测试验证LSP

使用NUnit进行契约测试：

[TestFixture] public class LspTests { [Test] public void TestRectangleSubstitution() { // 创建形状列表 var shapes = new List<Shape> { new Rectangle(), new Square() }; // 遍历每个形状 foreach(var shape in shapes) { // 设置宽度和高度 shape.Width = 5; shape.Height = 4; // 断言面积是否为20 Assert.That(shape.Area, Is.EqualTo(20)); } } } 八、最佳实践总结 优先使用组合而非继承保持继承层次扁平化使用设计模式： 策略模式模板方法模式装饰器模式 定期进行代码审查编写契约测试 九、现实应用场景 支付系统：// 抽象支付提供者 public abstract class PaymentProvider { // 抽象支付方法 public abstract void ProcessPayment(decimal amount); } // 信用卡支付实现 public class CreditCardPayment : PaymentProvider { /*...*/ } // PayPal支付实现 public class PayPalPayment : PaymentProvider { /*...*/ } 日志系统：// 日志接口 public interface ILogger { // 日志记录方法 void Log(string message); } // 文件日志实现 public class FileLogger : ILogger { /*...*/ } // 数据库日志实现 public class DatabaseLogger : ILogger { /*...*/ }

遵循LSP能够创建出更健壮、更易维护的系统架构。记住：好的继承关系应该表现为"is-a"的关系，而不是"is-like-a"。当发现子类需要修改父类核心行为时，这往往是一个设计需要改进的信号。