1. 多态的本质从一段到处是 if/else 的代码说起如果你维护过一个订单模块一定见过这种代码根据订单类型、支付方式、折扣规则写出几十行 if/else每加一种新类型就要把所有分支点翻一遍改完还要提心吊胆怕影响老逻辑。我最初是在这种场景里真正理解了 C#4.0 的多态——它不只是一章语法而是一套“让对象自己决定行为”的组织方式。这一章的标题虽然挂在 C#4.0 下但里面的概念放到今天依然不过时而且越早想明白后面写代码越省事。1.1 编译期类型与运行时类型一次方法调用的完整旅程很多人背过多态的定义同一操作作用于不同对象产生不同行为。但真正写代码时最容易被绕进去的是“引用变量的类型”和“对象真实类型”不一致的问题。Shape s new Circle(); s.Draw();这行代码里有两件事编译期s的静态类型是Shape编译器只允许你调用Shape上定义的方法运行期s实际指向的是Circle对象如果Draw被声明为虚方法且Circle重写了它那么真正执行的逻辑来自Circle.Draw。我把这个过程理解为编译器在门口检查你有没有“资格”调用这个方法真正的路由是运行时通过虚方法表完成的。C# 中普通方法默认不是虚的必须显式写virtual子类再写override这一对关键字出现的时候才意味着“我想把行为决策权交到运行时手里”。1.2 从 C 的虚函数表看 C# 的分发机制如果你之前学过 C再来看 C# 的多态会特别亲切。C 用虚函数表vtable记录每个类的虚方法地址对象内部藏着一个指向 vtable 的指针。C# 的 CLR 也有类似机制虽然细节不同但本质都是每个对象在运行时要能顺着自己的实际类型找到对应的方法实现。这也是为什么 C# 默认方法非虚——和 C 一样避免所有方法都承担额外查找开销也避免无意间被子类重写破坏逻辑。Java 里普通实例方法默认可以重写到了 C# 必须显式声明这种设计差异决定了 C# 在类库设计时更强调“扩展点要明确”。1.3 多态解决的是“变化的隔离”不是让你炫技接触多态之后很容易走另一个极端到处建基类、抽接口、加虚方法结果代码比 switch 还难读。多态真正干的事是把“根据类型做分支”的复杂度从调用方搬到类型层级里去。举个简单例子没有多态时绘制图形的代码长这样public void DrawShape(Shape s) { if (s is Circle) DrawCircle((Circle)s); else if (s is Rectangle) DrawRectangle((Rectangle)s); else throw new NotSupportedException(不支持的图形); }一旦新增三角形你得回来改这个函数。而用多态public void DrawShape(Shape s) { s.Draw(); }调用方不再关心对象到底是哪种图形新类型的插入点是新建类并重写Draw。这就是我在读这一章时印象最深的结论多态的收益不是少写几个 if而是把“当类型变化时你要修改哪里”这个问题的答案从“到处改”变成“只加不改”。2. C# 实现多态的三种载体虚方法、抽象类与接口《C#4.0权威指南》这一章把多态的实现方式拆成了三条路虚方法、抽象类、接口。它们都能让同一个引用调用出不同行为但适用场景差别很大选错了后面会非常痛苦。2.1 虚方法适合“大部分逻辑共用少数步骤定制”虚方法多态是最经典的形式。基类把通用流程写好把可变化的地方用virtual标出来子类用自己的override替换细节。public class Document { public void SaveToFile(string path) { Validate(); WriteHeader(path); WriteBody(path); } protected virtual void Validate() { Console.WriteLine(文档基础校验); } protected virtual void WriteBody(string path) { Console.WriteLine(写出纯文本内容); } private void WriteHeader(string path) { Console.WriteLine(写入公共文件头); } } public class PdfDocument : Document { protected override void Validate() { Console.WriteLine(PDF专用校验检查排版资源); } protected override void WriteBody(string path) { Console.WriteLine(写出PDF对象流); } }这里的价值在于SaveToFile这个工作流不需要改子类只需要覆盖流程中的某个环节。我在实际项目里常用这种模式处理报表导出基类负责打开文件、创建资源、关闭流子类只管把内容序列化成自己的格式。注意一点virtual方法不能是private通常用protected或public因为子类需要重写它。2.2 抽象类强制子类完成“半成品”的剩余部分抽象类是比虚方法更强硬的约束。抽象方法没有方法体子类如果不重写自己也只能是抽象类无法实例化。它适合表达“这东西是个不完整模板你来补全”。public abstract class Logger { public void Log(string message) { string formatted Format(message); Write(formatted); } protected abstract string Format(string message); protected abstract void Write(string message); } public class FileLogger : Logger { protected override string Format(string message) { return DateTime.Now.ToString(yyyy-MM-dd HH:mm:ss) message; } protected override void Write(string message) { File.AppendAllText(app.log, message Environment.NewLine); } }抽象类还可以带字段、构造函数和普通方法这一点接口做不到。实践中我倾向于用抽象类管理“既有公共状态又有强制子类实现的骨架”的场景。但不要为了少写字硬抽抽象类层级过浅时抽象类反而让子类承担不必要的爹味约束。2.3 接口只定义契约不掺和实现C#4.0 里的接口成员默认是公共的不能包含字段、不能写方法体。它的核心价值是“多身份”同一个类可以实现多个接口在不同上下文扮演不同角色。public interface IWaterSwimmer { void Swim(); } public interface IRunner { void Run(); } public class Human : IRunner, IWaterSwimmer { public void Run() { Console.WriteLine(跑步); } public void Swim() { Console.WriteLine(游泳); } }调用方只需要依赖接口public void StartRace(IRunner runner) { runner.Run(); }接口多态适合定义能力不适合表达“骨肉相连”的继承关系。比如“能游泳的”和“能跑的”是两个能力维度强行用基类表达反而荒谬。2.4 三种载体的选择对照表维度virtual/override抽象类接口关键修饰符virtual、overrideabstractinterface、接口实现是否能带字段能能不能C#4.0是否能提供实现能能提供普通方法实现不能C#4.0约束强度可选重写抽象成员必须重写必须全部实现身份数量单继承链单继承链可实现多个适用场景定制流程中的环节不完整模板能力契约这个表我建议贴在显示器旁边。每次选型时先问自己我到底需要单亲继承的“家族相似性”还是只需要“一份行为合同”多态的正确姿势是让继承表达“是不是”让接口表达“能不能”。3. override、new 与重载三种“同名方法”的纠葛这一章里最容易被忽略、也最容易写错的地方就在这里同样是同名方法override、new和“重载”是三件完全不同的事。我见过不少同事把new当override用结果基类引用调用出来的行为和自己预期差了一截。3.1 new 隐藏方法这看起来像重写但不是public class Base { public void Foo() { Console.WriteLine(Base.Foo); } public virtual void Bar() { Console.WriteLine(Base.Bar); } } public class Derived : Base { public new void Foo() { Console.WriteLine(Derived.Foo); } public override void Bar() { Console.WriteLine(Derived.Bar); } }调用结果取决于引用类型Base b new Derived(); b.Foo(); // 输出 Base.Foo因为 Foo 不是虚方法new 只是隐藏 b.Bar(); // 输出 Derived.Bar因为 Bar 经过虚方法分发 Derived d new Derived(); d.Foo(); // 输出 Derived.Foonew做的事是给派生类提供一个同名新方法把基类的版本“藏”起来但它不参与虚分发表。当外部拿着基类引用时走的还是基类的方法。这个坑特别隐蔽尤其是代码里既有new又有virtual/override混用的时候。我在项目里的规矩很简单如果只是想“换掉”基类方法请先确认是否需要多态。需要多态就用override不需要就考虑换一个方法名而不是用new。new并不是不能用但它是刻意为之必须有注释说明意图。3.2 重载编译期就决定好的“静态多态”重载是同一个类里定义同名但参数列表不同的方法public class Printer { public void Print(string content) { /* 文本处理 */ } public void Print(int number) { /* 数字处理 */ } }调用Print(100)还是Print(100)编译器在编译期就能根据实参类型确定。所以重载常被称为编译时多态或者静态多态。它和继承、虚方法都没有直接关系不需要virtual也不存在运行时分发。一个常见误区是试图用重载来达到“不同类型不同行为”。比如写Process(Circle c)和Process(Rectangle r)是重载但实际传入时如果变量类型是基类Shape编译器会选择Process(Shape)的版本而不是根据运行时类型自动选Process(Circle)。这就是重载和多态最本质的差异也是很多人在调用重载方法时出现“我以为会调这个实际调了那个”的原因。3.3 绑定时机决定行为归属方法类别关键写法绑定时机核心问题虚方法重写virtual override运行时引用类型是基类行为来自实际对象隐藏方法new编译期引用类型不同调用结果不同重载参数列表不同编译期只看实参静态类型不看运行时类型把这三件事分开比死记“多态有几种”有用得多。日常 Code Review 时看到基类引用调用同名方法我第一个反应就是确认它是 override 还是 new因为这一步判断错了后面所有输出都解释不通。4. C#4.0 给多态带来的新变量dynamic、协变与逆变这一章既然叫 C#4.0 权威指南就不能绕过 4.0 时代最重要的三个语法特性dynamic、泛型协变、泛型逆变。它们不是在原有虚方法体系上锦上添花而是从两个维度把“多态”这个概念撑大了一个维度是绕过编译期类型检查另一个维度是让泛型接口重新获得类型方向上的灵活性。4.1 dynamic把方法绑定的决定权推迟到运行时C#4.0 引入的dynamic类型让变量在编译期不固定类型方法调用、属性访问都在运行时解析。你可以写出这样的代码dynamic shape GetShape(); shape.Draw();shape是Circle时调用Circle.Draw是Rectangle时调用Rectangle.Draw。看起来和接口多态很像但底层逻辑完全不同。接口多态靠的是对象实现了约定的IDrawable而dynamic靠的是运行时用反射去查找“有没有一个叫 Draw 的方法”找不到就抛出RuntimeBinderException。dynamic最实用的场景是 COM 互操作、动态语言互操作以及调用反射 API 时省掉一大串Activator和GetMethod的代码。但在普通业务代码里我不推荐拿它代替接口多态。原因有三一是性能开销运行时绑定比直接虚方法调用慢二是编译期保护没了字段、方法名写错了要到运行时报三是代码可读性差读者很难一眼看出shape到底能干什么。如果你发现自己是在用一个dynamic来假装接口那说明这里其实缺一个明确的接口。4.2 协变让泛型类型参数顺着继承方向转换C#4.0 为泛型接口和委托引入了out和in关键字。以前写IEnumerableT你不能把一个IEnumerableDog直接赋给IEnumerableAnimal即使Dog继承自Animal。C#4.0 之后因为IEnumerableout T被标记为协变这个赋值合法IEnumerableDog dogs new ListDog(); IEnumerableAnimal animals dogs;注意ListT本身不是协变的所以ListAnimal list new ListDog()仍然编译不过。协变只出现在“只读”方向的接口上out意味着类型参数只出现在输出位置。这个特性非常贴合多态的思想既然Dog是Animal的一种那么一个“能产出 Dog 的序列”也应该是“能产出 Animal 的序列”的一种。泛型方向上的多态让我们写出来的 API 更容易满足“里氏替换”。4.3 逆变比较器、处理器这类“消费型”接口的灵活赋值逆变正好相反。in关键字表示类型参数只出现在输入位置。最典型的例子是IComparerin TIComparerAnimal animalComparer new AnimalComparer(); IComparerDog dogComparer animalComparer;一个能比较所有动物的比较器当然也能比较狗。这就是逆变类型参数的方向和继承方向相反。C#4.0 时期协变逆变只支持泛型接口和泛型委托不支持泛型类理解这一点可以避免踩“为什么我的IRepositoryT不能这样赋值”的坑。我在实际项目中用协变摆脱过不少类型转换痛苦。比如业务层返回IEnumerableEntity数据层实际给的是ListDerivedEntity以前要么CastT()要么手动转换有了协变之后直接赋值少写一层样板代码。4.4 静态多态、运行时多态和动态绑定的关系整理机制类型检查时机典型语法风险重载编译期同名不同参需求对“运行时类型”敏感时不适用虚方法/抽象类/接口运行时virtual、override、abstract、interface需要正确设计继承层次dynamic运行时dynamic 关键字方法名错、类型错到运行时才暴露泛型协变/逆变编译期out、in类型参数方向写错会导致无法赋值这四个东西共享一个思想调用的正确性不取决于“你把对象看成什么类型”而取决于“对象实际能做什么”。5. 实战重构把支付流程中的 switch 换成多态后的变化光讲概念容易飘我在文章开头提到的订单模块就是被支付代码折磨过。当时支付方式已经从两个涨到五个Pay方法里的 switch 越来越长而且每种支付方式还各有一段完全不同的回调处理。我照着多态那一章的思路把支付流程重写了一遍效果很直观。5.1 最开始的坏味道代码public void Pay(Order order) { switch (order.PaymentMethod) { case PaymentMethod.Alipay: Console.WriteLine(调起支付宝SDK); Console.WriteLine(组装支付宝订单参数); // 后面还有几十行业务逻辑 break; case PaymentMethod.WeChat: Console.WriteLine(调起微信SDK); Console.WriteLine(组装微信订单参数); break; case PaymentMethod.UnionPay: Console.WriteLine(调起银联SDK); break; default: throw new NotSupportedException(不支持的支付方式); } order.Status OrderStatus.Paid; }问题不在 switch 本身而在于这个 switch 复制到了订单查询、退款、对账三个模块每个模块都要再维护一份“支付方式专属逻辑”。新增支付方式要改的地方不是一两处而是所有出现的点。5.2 用多态把支付方式的差异封装成类我先定义一个支付处理器接口public interface IPaymentProcessor { void Pay(Order order); }然后让每种支付方式成为一个实现类public class AlipayProcessor : IPaymentProcessor { public void Pay(Order order) { Console.WriteLine(调起支付宝SDK); Console.WriteLine(组装支付宝订单参数); } } public class WeChatProcessor : IPaymentProcessor { public void Pay(Order order) { Console.WriteLine(调起微信SDK); Console.WriteLine(组装微信订单参数); } }调用方再也不用关心“支付宝怎么组装参数”它只需要依赖IPaymentProcessorpublic void Pay(Order order, IPaymentProcessor processor) { processor.Pay(order); order.Status OrderStatus.Paid; }5.3 工厂仍然要保留一个 switch但只出现一次有人会问订单还是需要从PaymentMethod枚举转成对应的IPaymentProcessor啊这步不做 switch 怎么做确实要做但只会出现一次放在工厂方法里public static class PaymentProcessorFactory { public static IPaymentProcessor Create(PaymentMethod method) { switch (method) { case PaymentMethod.Alipay: return new AlipayProcessor(); case PaymentMethod.WeChat: return new WeChatProcessor(); case PaymentMethod.UnionPay: return new UnionPayProcessor(); default: throw new NotSupportedException(不支持的支付方式); } } }这个设计的关键是多态不会消灭所有 switch它把 switch 压缩到了一个可控的创建点。新支付方式到来时核心支付流程代码不需要动只需要新增一个类再在工厂里注册一行。这样风险范围被限制在“新增代码”而不是“修改旧代码”。5.4 测试和扩展因此变得容易重构之前支付流程的单元测试很难做因为Pay方法里直接 new 了各种 SDK 的静态调用。重构之后我可以手写一个假的支付处理器扔进去public class FakeProcessor : IPaymentProcessor { public bool Called { get; private set; } public void Pay(Order order) { Called true; } }然后在测试里断言Called是否为真订单状态是否正确。整个流程不需要依赖真实第三方支付平台。这就是多态给测试带来的直接回报依赖抽象而不是依赖具体实现替换和模拟都容易了。6. 多态使用中我最想提醒的五个坑多态用好了确实漂亮但用不好时排查问题远比 switch 更费劲。这一章读下来我结合自己踩过的坑总结几个特别想提醒的细节。6.1 构造函数里调用虚方法对象还没准备好就提前演出构造函数中调用虚方法是个著名的坑C#、Java、C 都有类似问题。看这个例子public class Base { public Base() { Print(); } public virtual void Print() { Console.WriteLine(Base.Print); } } public class Derived : Base { private string name; public Derived(string name) { this.name name; } public override void Print() { Console.WriteLine(name ?? null); } }执行new Derived(hello)时先调用Base的构造函数Base构造函数里调用Print虚分发会进入Derived.Print但此时Derived构造体还没有执行name还是空。这个问题的本质是基类构造阶段派生类字段尚未初始化却已经拿到了多态控制权。规避方法很简单构造函数里只做必要的基础初始化不要调用任何可能被重写的虚方法。真要有“初始化后统一执行”的逻辑宁可提供一个显式的Init方法。6.2 脆弱基类问题基类改一个字符子类一片倒下多态意味着子类对基类的行为高度依赖。如果基类里一个原本非虚的方法被改成虚方法或者一个虚方法内部多了几步新逻辑所有子类都可能产生行为变化。这种“基类一动后方失火”的现象叫脆弱基类问题。我在团队里立过一条约定基类中非虚方法尽量保持非虚不要为了“以后可能需要扩展”提前把所有方法都标成virtual。虚方法是一个公共 API 承诺一旦放出去你就得一直为它的行为负责。扩展点应该按真实需求开而不是按想象力开。6.3 显式接口实现与多态的两个身份当一个类实现了两个接口而两个接口恰好有同名方法时就需要显式接口实现。这时多态的表现和“类方法调用”不同public interface IRead { void Load(); } public interface IWrite { void Load(); } public class Config : IRead, IWrite { void IRead.Load() { Console.WriteLine(IRead.Load); } void IWrite.Load() { Console.WriteLine(IWrite.Load); } }调用时Config c new Config(); c.Load()是编译不过的必须通过接口引用调用。这意味着多态不再由对象本身决定而是由“你通过哪份合同去看这个对象”决定。很多人被这个问题卡住不是不懂多态而是没意识到接口本身也是类型引用类型决定了可见的方法集合。6.4 重写 Equals/GetHashCode 后集合里出现寻址错乱C# 的GetHashCode和Equals都带有天然的多态性重写它们时如果不小心会把字典、哈希集合搅乱。比如Person重写了Equals按 Id 比较Employee继承后又加了一个部门字段重写Equals时同时比较部门和 Id。当同一个逻辑里使用DictionaryPerson, string一会儿放入Person一会儿查询Employee哈希码可能不同导致查找失败。这不代表不要重写而是重写时要想清楚这个类型的相等性在多态场景下是否稳定。跨层重写相等性最好用独立的IEqualityComparerT而不是塞进继承链里。否则一个看似简单的多态行为会成为数据结构的定时炸弹。6.5 多态不是越多越好最后这条可能是全部经验里最值钱的。多态把复杂度从调用方转移到了类型层级里如果层级设计本身就乱多态就是放大乱。基类塞了十几个虚方法子类重写一半留一半代码看起来“很面向对象”实际难读得要命。我在 Code Review 时看到 switch不会立刻要求改成多态。我会先问一句这个类型列表的变化频率高不高如果新增类型时需要考虑的分支点只有这一处那 switch 完全没问题。如果同样的类型判断散落在七八个方法里每个方法都要维护分支那才是多态出场的时候。把多态用在变化点上而不是用在所有同名方法上这才是 C#4.0 这一章教会我的最实用的判断标准。