降低大型开关语句的复杂性

在我目前正在处理的代码库中，通常必须从进一步向上链接传入一个字符串，并将其用作查找不同字符串的关键字。目前的标准习惯是使用switch语句，但是对于较大的switch语句（想想20-30个例子），sonarqube说这是一种代码味道，应该减少圈复杂度。我目前的解决方案是使用一个静态HashMap中，像这样降低大型开关语句的复杂性

private static final HashMap<String, String> sortMap; 
static { 
    sortMap = new HashMap<>(); 
    sortMap.put("foo1", "bar1"); 
    sortMap.put("foo2", "bar2"); 
    sortMap.put("foo3", "bar3"); 
    etc... 
} 

protected String mapSortKey(String key) { 

    return sortMap.get(key); 
}

然而，这似乎并没有实际上的任何清洁剂，如果有什么似乎是维护更加混乱。有没有更好的方法来解决这个问题？或者在这种情况下sonarqube应该被忽略？我知道使用多态性，即Ways to eliminate switch in code，但是这看起来对于这个问题是过度的，因为switch语句被用作临时数据结构而不是基本的多态性。在这种情况下，我发现的有关减少开关盒复杂度的其他类似问题并不真正适用。

来源

2017-10-17 JCD

你不能将映射外包到一个文件中并从那里读取它吗？这种方法更具活力。比在程序中硬编码100个开关大小写语句或map-puts更好。除此之外，我认为地图方法更加干净。但我没有看到你需要在这里使用* static-blocks *的原因，我不喜欢他们... – Zabuza

https://blog.sonarsource.com/cognitive-complexity-because-testability-understandability “甚至McCabe在他的原始论文中承认，在开关中处理病例陈述似乎并不完全正确”，关于圈复杂性。所以你可以决定忽略它。 – Kayaman

@ zero298我觉得使用多态不是解决这个问题的正确方法，因为现在使用switch语句的方式是作为基本的数据结构，而不是确定要运行的方式。 – JCD

如果你举个例子，这只是从键中选择映射值的情况下，表或属性文件将是一个更合适的方式来处理这个问题。

如果您在讨论不同switch语句中的逻辑，您可能会发现规则引擎更适合。

您碰到了主要要求：可维护性。如果我们编写的逻辑太多或数据太多，我们已经做出了脆弱的代码。选择一种适合于切换信息类型的设计模式，并将功能导出到一个可维护的位置，供稍后必须做出更改的人员使用...因为这样一份长长的清单，很可能会发生一些频率变化。

来源

2017-10-17 20:22:44

降低大型开关语句的复杂性

回答

相关问题