降低大型開關語句的複雜性

在我目前正在處理的代碼庫中，通常必須從進一步向上鍊接傳入一個字符串，並將其用作查找不同字符串的關鍵字。目前的標準習慣是使用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

降低大型開關語句的複雜性

回答

相關問題