Question

我正在寻找充分的理由，如果我们应该尝试避免切换/案例语句以及如何对枚举进行此操作，并提出建议，请考虑以下示例：（请注意，此开关/案例可能分散在整个代码库中）

switch (theEnum)
{
    case MyEnum.Enum1:
        // dosomething
    case MyEnum.Enum2:
        // do something
    case MyEnum.Enum3:
        // do something
    default:
       throw new Exception("Unsupported enumeration: " + theEnum.ToString());

}

VS

public Dictionary<MyEnum, StrategyBase> BuildMapper()
{
    var mapper = new Dictionary<MyEnum, StrategyBase>();
    mapper[MyEnum.Enum1] = new Strategy1();
    mapper[MyEnum.Enum2] = new Strategy2();
    mapper[MyEnum.Enum3] = new Strategy3();
return mapper;
}

BuildMapper()[MyEnum.Enum1].DoSomething();

选项2更多OO，但我想知道其他人认为这种方法是什么，以及是否有充分和令人信服的理由我们应该努力做到这一点。

有人可能认为诸如switch / else之类的原则会违反开放式关闭。

Answer 1

对于OO，您应该使用Visitor Pattern

Answer 2

我会将BuildMapper设为静态（以及只读），因为它总会返回相同的字典集。

至于为什么这是好的，原因应该是简单的，当你有一个设计，事物从一个事物映射到另一个，这个映射将永远是静态的，很明显将其表示为字典，而不是如果/否则或切换案例隐藏它只是一个映射的意图。

Answer 3

如果只是在一两个地方，我会去转换。如果你说的话，“这个开关/案例可能会分散在整个代码库中”，那么请选择第二个解决方案。

这不仅仅是更多OO，这是好的，但在您的情况下更容易维护。在这种情况下，对性能和内存消耗的担忧是完全无关紧要的，首先是易于维护并在需要时进行优化（但我认为您不需要优化 this ）。

在这种情况下，可读性损失也是无关紧要的 - 了解第二种方法的作用只需要很短的时间。

Answer 4

我认为第一个变体更好，因为它看起来更具可读性和显性。

Answer 5

我想说这一切都取决于你想要达到的目标。它更容易阅读第一个示例，如果您与其他人共享代码库，这一点很重要。如果您遵循某种模式

，BuilderMapper可能会很有用

Answer 6

我猜你是在比较橘子和苹果。

开关是变量和几个常量数据之间的顺序比较。除非你有一个1K案例的开关，它应该比字典表现更好。

当然，与字典一样，交换机的内存消耗要少得多。

最后，枚举不限于声明的选项，但可以合并为“标志”。使用hashmap将无法使用此功能。

令人满意吗？

枚举和案例陈述

6 个答案: