在從文件讀取更好的數據行之前，枚舉有多復雜（例如.csv）？

Question

我創建了一個平台游戲的一部分，其中有一個演員類，代表對象和角色的實例，以及一個類型枚舉，表示每個演員將擁有哪些數據（例如速度，攻擊，防御等）。 使用硬編碼的枚舉定義來指定每種類型的所有數據似乎有些乏味。 例如

PLANE("Plane", 10, 10, 2, 0),
MISSILE("Missile", 1, 0, 0, 4);

最好在文件中指定數據並讀取它嗎？

Answer 1

我對該問題的回答現在是：為此使用DSL，例如使用Kotlin（在Groovy中可能有類似的事情）。

無需贅述，以下內容可能是有效的Kotlin（實際上是從生產系統復制的工作代碼）：

buildTreats {
    category(BEVERAGE) {
        treat(id = 2, key = "bonusfood.treat.appleJuice") {
            47.kcal
            0.5 of GLASS
        }
    …
    }
    …
}

這樣做的好處是您具有完整的代碼完成和編譯時檢查，而這些檢查和檢查是CSV文件無法做到的。

Answer 2

這里的一些想法：

• 與其為枚舉提供“易於閱讀的”名稱字符串，還可以@Override toString（）方法自動返回Plane for PLANE（簡單-僅將首字母以外的所有內容都小寫）
• 這樣的代碼破壞了您以后添加更多功能的能力

有一個古老的開放/封閉原則 。 基本上是這樣說的：您的代碼需求應該在最有可能發生更改的區域中公開 。

我敢肯定：今天你需要4個值，比如10, 10, 2, 0為一個平面，如上述。 但是幾天后，您可能希望擁有更多屬性。 然后，您必須轉到所有枚舉常量並更新它們。

在這個意義上，它可能是更好地放棄了一下這里編譯時的安全性; 並改用地圖。 地圖鍵可以是一個枚舉（僅列出某些玩家/物品/ ...具有的不同潛在屬性）。 映射鍵將是該強度的特定值。

如果您想沿這條路線走，則可以為每個枚舉常量指定一個類型 。 因此，您知道例如STRENGTH的映射值將是Integer對象或類似的對象。

換句話說：您可能會在這里變成反射的黑暗境界。

Answer 3

enum的美麗之處在於它們固定在代碼中並且不會更改。 這在編碼，類型檢查時提供了巨大的好處，您可以使它們成為Map和Set ，並且可以遍歷它們甚至切換大小寫（盡管現在已經不那么普遍了，它們可以具有自己的功能）。 您甚至可以將它們保存在數據庫中，只要您使用它們的名稱，即使枚舉列表發生更改，數據仍然可以正確地映射回去。

因此，我不會放棄它們，我可能會添加一個新的名稱，也許是“ OTHERS”，它可以以某種方式提供任何實驗性的新名稱。

如果您的核心問題是繁瑣的參數維護，那么請務必使用靜態初始化程序從配置中讀取該數據。