關於如何在復雜的紙牌游戲中平衡多態/繼承/類型數據架構與原型/享元模式的技巧？

Question

我正在嘗試使用 Kotlin 開發紙牌游戲，但我覺得我覺得必須做出的復雜架構決策正在拖延我的進程。 我想為可能具有不同效果、不同類型（例如咒語、車輛、武器……）的數十種不同的卡片創建一個堅實而靈活的基礎。

直覺上，我覺得給每個不同的Card自己的子類是荒謬的，原因有幾個，比如失去靈活性（不能（沒有瘋狂的黑客）動態地創建新類型的卡片）和不斷升級的復雜性。

另一方面，會有不同類別的卡片（類型），它們之間的共同點通常比卡片更多——所以感覺我絕對應該將Card子類化，否則我最終會得到類型枚舉（SPELL、WEAPON、 VEHICLE...) 和丑陋的 switch 語句取代了通常由繼承和多態處理的內容。

我最初在構思如何訪問位於超類集合中的子類的特定行為時遇到了問題，但現在我明白了如何使用訪問者模式解決這個問題 - 到目前為止一切都很好。

我現在的問題是這種架構方法似乎與我計划的其他事情發生沖突，我認為這是必要的或至少非常值得擁有的： 原型-蠅量級模式的混合：我創建了一個原型卡的“百科全書”，可以復制的。 卡片由共享的靜態部分和唯一的動態部分組成：

當然，我想通過以下方式創建標識組件的子實例：

無論我如何處理，似乎都不可能以令人滿意的方式做到這一點。 有很多解決方案，但對我來說似乎都是微弱的妥協：

• 按照我描述的方式進行操作意味着子類必須保存對其組件的多個引用； 每個基類和一個子類。 它還導致了一種丑陋的情況，其中類型屬性分布在幾個相互依賴的組件類中。
• 使用接口而不是繼承會導致大量的代碼重復。
• 僅子類化組件而不是卡片本身會將類型信息隱藏在卡片的內部，並且還需要丑陋的反射來訪問子類特征。
• 實現類型信息的數據等價物而不是子類化以規避 Kotlin 繼承層次結構的限制規則似乎很棘手，並刪除了 IDE 支持。

我確信在過去的兩周里我考慮過更多的方法，但我現在只記得這些。

我知道您可能需要關於我打算做什么的更完整的信息來給我具體的答案，但由於它太復雜了，而且我也不知道這是怎么回事，我對這些粗略的想法感到滿意“考慮這個”或“不管你在做什么，遠離這個”或關於如何處理這樣一個“設計危機”的一般建議，事情看起來如此復雜，你不知道如何開始。

當然，如果有必要，我准備詳細說明或詳細說明我的描述的某些部分。

Answer 1

只想到這里。

如何創建一個帶有 Card 低級公共部分的 BaseCard 類，然后為從 BaseCard 繼承的每個類別創建一個類，命名為 Category，您可以在其中存儲每個類別的公共部分，然后類 CardofSomeType 從其各自的 Category 繼承。 因此，在 CardofSomeType 中，您可以從任一類繼承任何相關內容，只需添加新 Card(s)ofSomeType(s) 即可擴展您的集合。

關於哪些數據是特定於實例的或在類中共享的，這與此以及每個類的實現細節是正交的。