你还在用 Switch 吗？揭秘 C# 中更高效的多态性与条件判断在最近的一次代码评审中，我收到了一条宝贵的建议："这个

前言

在最近的一次代码评审中，我收到了一条宝贵的建议："这个switch语句是反模式，建议改用多态性实现。"这不仅引起了我的深思——为何现代软件设计要避免"switch式多态"？如果你使用过C#（或其他面向对象语言），或许也遇到过类似的建议。

本文将深入探讨这种反模式的根源，并学习正确的重构方法。

过度使用Switch语句的隐患

当我们通过类型或枚举值来决定行为时，冗长的switch语句可能违反开闭原则（OCP）——SOLID设计原则的核心之一。

OCP要求代码对扩展开放，对修改关闭。随着新条件的不断添加，switch语句迫使开发频繁修改既有代码，导致系统变得脆弱且难以维护。

但需注意的是，并非所有switch语句都需要替换为多态性。如果条件分支有限、稳定且易于理解，那么switch语句反而是更优的选择。实用主义应始终优先于盲目套用设计模式。

典型需重构的Switch案例

以支付系统为例：

public class PaymentProcessor  
{  
    public void ProcessPayment(PaymentType paymentType)  
    {  
        switch (paymentType)  
        {  
            case PaymentType.CreditCard:  
                ProcessCreditCardPayment();  
                break;  
            case PaymentType.PayPal:  
                ProcessPayPalPayment();  
                break;  
            case PaymentType.Bitcoin:  
                ProcessBitcoinPayment();  
                break;  
            default:  
                throw new ArgumentException("Unsupported payment type");  
        }  
    }  
}

表面看似合理，但每次新增支付方式都需修改此switch语句，这明显违反了OCP原则，增加了维护成本和潜在bug的风险。

何时该用多态性重构？

当预期条件分支会持续扩展时，应考虑以下步骤进行重构：

1、定义支付处理的抽象基类/接口。

2、为每种支付方式实现具体类。

3、使用依赖注入或工厂模式实例化对象。

重构后的多态实现：

public interface IPaymentProcessor  
{  
    void ProcessPayment();  
}  

public class CreditCardPaymentProcessor : IPaymentProcessor  
{  
    public void ProcessPayment()  
    {  
        // 信用卡支付处理逻辑  
    }  
}  

public class PayPalPaymentProcessor : IPaymentProcessor  
{  
    public void ProcessPayment()  
    {  
        // PayPal支付处理逻辑  
    }  
}  

public class BitcoinPaymentProcessor : IPaymentProcessor  
{  
    public void ProcessPayment()  
    {  
        // 比特币支付处理逻辑  
    }  
}

高性能依赖注入方案（.NET 8特性）：

// 使用键控单例实现O(1)查找  
services.AddKeyedSingleton<IPaymentProcessor, CreditCardPaymentProcessor>(PaymentType.CreditCard);  
services.AddKeyedSingleton<IPaymentProcessor, PayPalPaymentProcessor>(PaymentType.PayPal);  
services.AddKeyedSingleton<IPaymentProcessor, BitcoinPaymentProcessor>(PaymentType.Bitcoin);  

// 动态解析处理器  
public class PaymentService  
{  
    private readonly IServiceProvider _serviceProvider;  

    public PaymentService(IServiceProvider serviceProvider) => _serviceProvider = serviceProvider;  

    public void ProcessPayment(PaymentType paymentType)  
    {  
        var processor = _serviceProvider.GetRequiredKeyedService<IPaymentProcessor>(paymentType);  
        processor?.ProcessPayment() ?? throw new InvalidOperationException("No processor found");  
    }  
}

何时应坚持使用Switch语句？

避免过度设计！如果业务场景稳定且无需扩展，switch语句可能是更优选择：

可读性强：逻辑简单且自包含。

性能更佳：编译器优化跳转表。

维护方便：无需频繁添加新条件。

适用场景示例

// 处理有限且固定的状态类型  
public enum ConnectionStatus { Connected, Disconnected }  

public void HandleConnection(ConnectionStatus status)  
{  
    switch (status)  
    {  
        case ConnectionStatus.Connected:  
            StartHeartbeat();  
            break;  
        case ConnectionStatus.Disconnected:  
            StopServices();  
            break;  
    }  
}

总结

Switch语句并非原罪，多态性亦非银弹。最佳选择取决于具体场景：

需要弹性扩展 → 采用多态性。

业务逻辑稳定 → 保持简单的switch。

当收到“建议改用多态性”的评审意见时，应视作优化代码的契机而非批评。优秀的软件设计需要预见变化的敏锐度、权衡利弊的决策力以及抵制教条主义的务实精神。下次编写条件判断时，不妨自问：是否存在更优雅、更具扩展性的实现方式？答案很可能就是肯定的。

真正的软件设计人员不仅解决当前问题，更构建抵御变化的系统。通过避免"switch式多态"，拥抱真正的多态性，你正在打造高弹性的架构、易维护的代码库以及面向未来的解决方案。

最后

如果你觉得这篇文章对你有帮助，不妨点个赞支持一下！你的支持是我继续分享知识的动力。如果有任何疑问或需要进一步的帮助，欢迎随时留言。

也可以加入微信公众号 [DotNet技术匠] 社区，与其他热爱技术的同行一起交流心得，共同成长！

优秀是一种习惯，欢迎大家留言学习！

作者：架构师老卢

出处：mp.weixin.qq.com/s/3J_fI1LLIJaf5tulU8xIJQ

声明：网络内容，仅供学习，尊重版权，侵权速删，歉意致谢！