应该何时尝试消除switch语句？

Question

我在我正在处理的代码库中遇到了一个switch语句,我正在试图弄清楚如何用更好的东西替换它,因为switch语句被认为是代码味道.但是,通过阅读有关替换switch 语句的 stackoverflow上的几篇文章,我似乎无法想到替换此特定switch语句的有效方法.

它让我想知道这个特定的switch语句是否正常,以及是否有特殊情况认为switch语句是合适的.

在我的情况下,我正在努力的代码(自然略微混淆)是这样的:

private MyType DoSomething(IDataRecord reader)
{
    var p = new MyType
                {
                   Id = (int)reader[idIndex],
                   Name = (string)reader[nameIndex]
                }

    switch ((string) reader[discountTypeIndex])
    {
        case "A":
            p.DiscountType = DiscountType.Discountable;
            break;
        case "B":
            p.DiscountType = DiscountType.Loss;
            break;
        case "O":
            p.DiscountType = DiscountType.Other;
            break;
    }

    return p;
}

任何人都可以建议消除这种转换的方法吗？或者这是一个合适的开关？如果是,那么switch语句还有其他适当的用途吗？我真的很想知道它们的适用位置,所以我不会浪费太多时间来消除我遇到的每一个开关语句,因为它们在某些情况下被认为是一种气味.

更新:根据迈克尔的建议,我做了一些搜索这个逻辑的重复,发现有人在另一个类中创建了逻辑,有效地使整个switch语句变得多余.所以在这个特定代码的上下文中,switch语句是不必要的.但是,我的问题更多的是关于代码中switch语句的适当性以及我们是否应该总是尝试在找到它们时替换它们,所以在这种情况下我倾向于接受这个switch语句是合适的答案.

Answer 1

这适用于开关语句,因为它使选择可读,并且易于添加或减去一个.

看到这个链接.

Answer 2

切换语句(特别是长语句)被认为是错误的,不是因为它们是switch语句,而是因为它们的存在表明需要重构.

switch语句的问题是它们在代码中创建了一个分支(就像if语句一样).每个分支必须单独测试,每个分支内的每个分支......嗯,你明白了.

也就是说,以下文章在使用switch语句方面有一些好的做法:

http://elegantcode.com/2009/01/10/refactoring-a-switch-statement/

对于您的代码,上面链接中的文章表明,如果您正在执行从一个枚举到另一个枚举的这种类型的转换,您应该将您的开关放在它自己的方法中,并使用return语句而不是break语句.我以前做过这个,代码看起来更干净:

private DiscountType GetDiscountType(string discount)
{
    switch (discount)
    {
        case "A": return DiscountType.Discountable;
        case "B": return DiscountType.Loss;
        case "O": return DiscountType.Other;
    }
}