从一次代码重构说起：我是如何用C# virtual方法让老项目支持新需求的
去年接手一个电商平台的支付模块维护任务时，遇到个典型场景：系统原有支付宝和银行卡支付功能，现在要接入微信支付。核心挑战在于——原有支付处理类已经稳定运行三年，任何直接修改都可能引发连锁反应。经过多种方案对比，最终通过virtual方法实现了零侵入式扩展，这个案例或许能给面临类似困境的开发者一些启发。
1. 支付模块的现状与痛点
当我们拿到这个2018年开发的支付模块时，其核心结构是这样的：
public class PaymentProcessor { public void ProcessPayment(PaymentRequest request) { if (request.Type == PaymentType.Alipay) { // 200行支付宝处理逻辑 } else if (request.Type == PaymentType.BankCard) { // 150行银行卡处理逻辑 } } public string GenerateReceipt() { // 通用收据生成逻辑 } }这个设计存在几个明显问题：
- 单一职责原则违反：一个类处理多种支付方式
- 开闭原则违反：新增支付类型必须修改ProcessPayment方法
- 可测试性差：无法单独测试某种支付逻辑
更棘手的是，线上每天有近10万笔交易通过这个类处理，直接重构的风险系数极高。我们需要找到一种最小修改方案来支持新支付渠道。
2. 方案选型：为什么选择virtual方法
面对这个场景，团队提出了三种技术方案：
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 直接修改原方法 | 实现简单 | 违反开闭原则，风险高 | 小型一次性项目 |
| 抽象类+继承 | 结构清晰 | 需要重写所有支付逻辑 | 全新系统设计 |
| virtual方法+override | 最小修改，扩展性强 | 需要合理设计基类 | 现有系统功能扩展 |
最终选择virtual方案的关键考量：
- 修改范围可控：只需将原方法改为virtual，不影响现有功能
- 渐进式重构：可以逐个支付方式迁移到新结构
- 兼容性强：新旧实现可以共存过渡
提示：当你的系统已经稳定运行且修改成本高时，virtual方法往往是平衡扩展性和稳定性的最佳选择。
3. 具体实现步骤
3.1 基础结构改造
首先将支付处理器改为可扩展结构：
public class PaymentProcessor { public virtual void ProcessPayment(PaymentRequest request) { // 保留原逻辑作为默认实现 if (request.Type == PaymentType.Alipay) { /*...*/ } else if (request.Type == PaymentType.BankCard) { /*...*/ } } // 收据生成保持通用逻辑 public string GenerateReceipt() { /*...*/ } }3.2 新增微信支付处理器
public class WeChatPaymentProcessor : PaymentProcessor { public override void ProcessPayment(PaymentRequest request) { if (request.Type == PaymentType.WeChat) { // 微信支付专属逻辑 InitWeChatSDK(); var prepayId = CreateWeChatOrder(); return GenerateWeChatPayParams(prepayId); } // 非微信支付仍走基类逻辑 base.ProcessPayment(request); } private void InitWeChatSDK() { /*...*/ } // 其他微信专属方法... }3.3 渐进式迁移策略
采用工厂模式实现平滑过渡：
public class PaymentProcessorFactory { public PaymentProcessor Create(PaymentType type) { return type == PaymentType.WeChat ? new WeChatPaymentProcessor() : new PaymentProcessor(); // 原有处理器 } }迁移路线图：
- 第一阶段：新增微信支付，不影响原有渠道
- 第二阶段：将支付宝处理迁移到AlipayPaymentProcessor
- 第三阶段：将银行卡处理迁移到BankCardPaymentProcessor
4. 关键细节与陷阱规避
在实际实现过程中，有几个需要特别注意的技术点：
4.1 virtual方法的设计规范
- 访问修饰符：应保持protected或public，private virtual没有意义
- 方法体保留：virtual方法必须有实现，不同于abstract
- 避免过度使用：只在真正需要扩展的地方使用virtual
4.2 正确处理base调用
在重写方法时，base调用是个双刃剑：
public override void ProcessPayment(...) { // 前置处理 LogPaymentAttempt(); // 选择性调用基类逻辑 if (/* 需要基类处理 */) { base.ProcessPayment(...); } // 后置处理 UpdatePaymentStats(); }4.3 单元测试策略
针对virtual方法的测试要点：
[Test] public void WeChatProcessor_Should_Fallback_To_Base_For_NonWeChat() { var processor = new WeChatPaymentProcessor(); var request = new PaymentRequest { Type = PaymentType.Alipay }; // 测试非微信支付时是否正确回退到基类 processor.ProcessPayment(request); // 验证基类行为 Assert.IsTrue(WasAlipayProcessed()); }5. 扩展应用：virtual的进阶模式
除了基本的重写模式，virtual方法还可以实现更灵活的设计：
5.1 模板方法模式
public abstract class PaymentProcessorBase { public void Process(PaymentRequest request) { Validate(request); var receipt = ProcessCore(request); // virtual方法 PostProcess(receipt); } protected virtual Receipt ProcessCore(PaymentRequest request) { // 默认实现 } }5.2 条件性重写
public class SmartPaymentProcessor : PaymentProcessor { public override void ProcessPayment(...) { if (DateTime.Now.Hour < 8) { // 凌晨时段特殊处理 ProcessNightMode(...); } else { base.ProcessPayment(...); } } }这次重构给我的最大启示是：在维护老项目时，最小化修改往往比追求理想架构更重要。virtual方法就像代码中的"扩展插槽"，能在保持系统主体稳定的前提下，为特定场景提供定制化入口。
