258 lines
6.5 KiB
Markdown
258 lines
6.5 KiB
Markdown
# 里氏替换原则
|
||
概念：
|
||
- 里氏替换原则（Liskov Substitution Principle，LSP）说的是：
|
||
==所有使用父类的地方，都应该能够无障碍地替换成子类，而程序行为仍然正确==
|
||
- 简单理解：
|
||
==子类必须真的能当父类来用，而不是“语法上能继承，逻辑上却不成立”==
|
||
|
||
通常用法：
|
||
1. 判断一个继承关系到底合不合理
|
||
2. 约束子类重写父类成员时，不要破坏原有规则
|
||
3. 提醒自己：如果继承后总要“特殊处理”，那通常应该改成组合或接口
|
||
|
||
核心理解：
|
||
1. 子类可以扩展父类功能
|
||
2. 但==不能破坏父类原本承诺的行为==
|
||
3. 如果父类能做的事，子类却突然“不支持”了，那往往就违反了里氏替换原则
|
||
|
||
----
|
||
# 经典反例
|
||
错误设计：
|
||
```csharp
|
||
class Bird
|
||
{
|
||
public virtual void Fly()
|
||
{
|
||
Console.WriteLine("鸟会飞");
|
||
}
|
||
}
|
||
|
||
class Sparrow : Bird
|
||
{
|
||
public override void Fly()
|
||
{
|
||
Console.WriteLine("麻雀飞走了");
|
||
}
|
||
}
|
||
|
||
class Penguin : Bird
|
||
{
|
||
public override void Fly()
|
||
{
|
||
throw new NotSupportedException("企鹅不会飞");
|
||
}
|
||
}
|
||
|
||
void LetBirdFly(Bird bird)
|
||
{
|
||
bird.Fly();
|
||
}
|
||
|
||
LetBirdFly(new Sparrow()); // 正常
|
||
LetBirdFly(new Penguin()); // 出错
|
||
```
|
||
|
||
问题：
|
||
- `LetBirdFly(Bird bird)` 这个函数相信：只要传进来的是 `Bird`，就能 `Fly()`
|
||
- 但 `Penguin` 继承了 `Bird` 后，却把“会飞”这个规则破坏了
|
||
- 这就说明：==`Penguin` 其实不应该直接继承这种“默认会飞”的 Bird==
|
||
|
||
----
|
||
# 更合理的改法
|
||
改法一：把“鸟”和“会飞”拆开
|
||
```csharp
|
||
abstract class Bird
|
||
{
|
||
public string Name { get; set; }
|
||
}
|
||
|
||
interface IFlyable
|
||
{
|
||
void Fly();
|
||
}
|
||
|
||
class Sparrow : Bird, IFlyable
|
||
{
|
||
public void Fly()
|
||
{
|
||
Console.WriteLine("麻雀飞走了");
|
||
}
|
||
}
|
||
|
||
class Penguin : Bird
|
||
{
|
||
public void Swim()
|
||
{
|
||
Console.WriteLine("企鹅在游泳");
|
||
}
|
||
}
|
||
|
||
void LetBirdFly(IFlyable bird)
|
||
{
|
||
bird.Fly();
|
||
}
|
||
|
||
LetBirdFly(new Sparrow()); // 正常
|
||
// LetBirdFly(new Penguin()); // 编译期就不允许，更合理
|
||
```
|
||
|
||
这样做的好处：
|
||
1. `Bird` 只表达“它是一只鸟”
|
||
2. `IFlyable` 只表达“它会飞”
|
||
3. 不会飞的鸟就不用为了继承而硬实现一个错误行为
|
||
|
||
----
|
||
# 怎么判断有没有违反
|
||
可以拿下面几个问题自检：
|
||
|
||
1. 子类是不是父类的一种？
|
||
- 如果读起来都别扭，那继承关系大概率有问题
|
||
2. 把子类对象传到父类参数的位置，原有代码还能正常工作吗？
|
||
- 如果经常要加 `if (对象是某某子类)`，设计就开始危险了
|
||
3. 子类有没有把父类原本支持的行为变成“不支持”？
|
||
- 例如：父类能 `Fly()`，子类却直接抛异常
|
||
4. 子类有没有偷偷加强限制？
|
||
- 父类允许任意正数，子类却只允许 1 到 10
|
||
5. 子类有没有把父类承诺的结果变弱？
|
||
- 父类保证成功，子类却经常返回空结果或失败
|
||
|
||
----
|
||
# 违反里氏替换原则的常见信号
|
||
1. 子类重写后直接抛 `NotSupportedException`
|
||
2. 子类必须靠很多 `if/else` 特判才能安全使用
|
||
3. 继承只是为了复用代码，但语义上并不是“is-a”关系
|
||
4. 子类把父类的规则改掉了，而不是扩展
|
||
|
||
补充：
|
||
- “能继承”不等于“该继承”
|
||
- 很多违反 LSP 的代码，表面上编译没问题，真正出问题的是业务逻辑
|
||
|
||
----
|
||
# 和继承的关系
|
||
里氏替换原则不是反对继承，而是告诉你：
|
||
|
||
- ==继承必须建立在真正的替换关系上==
|
||
- 如果子类不能稳定替换父类，就不要硬继承
|
||
- 这时通常优先考虑：
|
||
- 组合
|
||
- 接口
|
||
- 更细的抽象拆分
|
||
|
||
所以可以把它和[[继承]]一起记：
|
||
- 继承解决“复用和扩展”
|
||
- 里氏替换原则约束“这个继承是不是合理”
|
||
|
||
----
|
||
# `is` 和 `as` 关键词怎么结合理解
|
||
先说结论：
|
||
|
||
- `is` 和 `as` 是==类型判断 / 类型转换工具==
|
||
- 它们能帮你在运行时判断“这个对象现在到底是什么类型”
|
||
- 但它们==不能证明一个继承设计就合理==
|
||
|
||
## `is`
|
||
作用：
|
||
- 判断对象是否兼容某个类型
|
||
- 也常用于模式匹配
|
||
|
||
例子：
|
||
```csharp
|
||
Bird bird = new Sparrow();
|
||
|
||
if (bird is Sparrow)
|
||
{
|
||
Console.WriteLine("这是麻雀");
|
||
}
|
||
|
||
if (bird is IFlyable flyable)
|
||
{
|
||
flyable.Fly();
|
||
}
|
||
```
|
||
|
||
理解：
|
||
- `bird is Sparrow` 的意思是：当前这个对象是不是 `Sparrow`
|
||
- `bird is IFlyable flyable` 不仅判断类型，还顺手把结果保存到变量 `flyable`
|
||
|
||
## `as`
|
||
作用：
|
||
- 尝试把对象安全转换成某个引用类型或可空值类型
|
||
- 转换失败不会抛异常，而是返回 `null`
|
||
|
||
例子：
|
||
```csharp
|
||
Bird bird = new Sparrow();
|
||
|
||
IFlyable flyable = bird as IFlyable;
|
||
if (flyable != null)
|
||
{
|
||
flyable.Fly();
|
||
}
|
||
```
|
||
|
||
补充：
|
||
- `as` 常用于引用类型
|
||
- 如果转换失败，结果是 `null`
|
||
- 对普通非可空值类型不能直接用 `as`
|
||
|
||
## 它和里氏替换原则的关系
|
||
`is` / `as` 本身没有错，但如果你发现代码里总是这样：
|
||
|
||
```csharp
|
||
void Handle(Bird bird)
|
||
{
|
||
if (bird is Sparrow)
|
||
{
|
||
// 一套逻辑
|
||
}
|
||
else if (bird is Penguin)
|
||
{
|
||
// 另一套逻辑
|
||
}
|
||
}
|
||
```
|
||
|
||
那通常说明一件事：
|
||
- 你嘴上写的是“我接收 `Bird`”
|
||
- 但你心里真正依赖的却是“具体子类是谁”
|
||
|
||
这往往意味着：
|
||
1. 抽象不够稳定
|
||
2. 多态没有真正用起来
|
||
3. 继承关系可能不够合理
|
||
4. 有概率正在逼着代码违反里氏替换原则
|
||
|
||
更好的方向一般是：
|
||
- 让父类 / 接口直接提供调用方真正需要的能力
|
||
- 或者把能力拆到更合适的接口里
|
||
|
||
一句话记：
|
||
- `is` / `as` 是“识别类型”的工具
|
||
- 里氏替换原则是“约束继承是否合理”的原则
|
||
- ==如果父类代码里到处都要靠 `is` / `as` 分辨子类，通常该反过来检查抽象设计==
|
||
|
||
----
|
||
# 一句话记忆
|
||
==子类可以扩展父类，但不能打破父类原来的承诺==
|
||
|
||
再压缩一点：
|
||
==父类能出现的地方，子类也必须能正常出现==
|
||
|
||
----
|
||
# 面试/复习时怎么说
|
||
可以这样答：
|
||
|
||
“里氏替换原则的意思是，子类对象必须能够替换父类对象，并且不影响程序原本的正确性。
|
||
如果一个子类继承了父类，却把父类原本支持的行为改成异常、限制更多条件，或者导致调用方需要额外特殊判断，那这个继承关系通常就不合理。
|
||
这时候应该考虑重新抽象，或者改成接口和组合。”
|
||
|
||
----
|
||
# 注意
|
||
1. 里氏替换原则是==设计原则==，不是语法规则
|
||
2. 它常和[[继承]]、[[多态vob|多态]]、[[接口]]一起理解
|
||
3. `is` / `as` 可以辅助做类型判断，但不能代替抽象设计
|
||
4. 只要你发现“某个子类总是不太像父类”，就该警惕是不是违反了 LSP
|
||
|
||
#核心
|
||
#设计原则
|