遊戲的建築模式

Question

所以我有一個包含幾個大項目的解決方案，我試圖將其分解爲更多獨立責任的較小項目。這是一款遊戲，但我主要是LOB開發人員，我認爲這些原則可能是普遍的，我想我可以在這裏學到一些東西。

某些對象的依賴關係有點過於緊密交織在一起，我希望對如何解決它們有所幫助。或者，也許某種模式或抽象可能會使他們更易於管理。

Ares.Core.World在其中有類似生物，物品等的類。它們都從實體繼承，實體知道地圖上存在的單元格。它通過持有對Ares.Core.UI.MapControls.MapCell的引用來實現此目的...並且您可以看到電線已經越過了。

Ares.Core.UI.MapControls包含Map和MapCell，其中每個都包含它們包含的生物和物品清單。 MapCell也繼承自Ares.Core.World.Entity，因爲它非常優雅地解決了一些早期的問題 - 例如，所有的實體都有庫存。

我想找到一種方法，用戶界面和世界拆分爲三個獨立的項目（Ares.World和Ares.UI），因爲UI和總體世界也許應該是單獨的擔憂。但正如你所看到的，現在這兩個項目需要相互引用，並且不允許循環引用。

我想知道是否有任何可能有助於這種情況的架構模式。謝謝！

Answer 1

所以，你的世界類 - 生物，物品等 - 他們都需要東西從MapCell。

您能合理地創建一個接口（或幾個）來表示世界實體需要什麼嗎？所以實體只需要實現該接口？

這將是解耦兩者的第一步。顯然，這個接口的方法簽名或屬性都不能包含UI項目中的類。應該使用標準類型或庫中的自定義類型定義World和UI參考（例如Ares.Core）。

然後，在UI項目中定義封裝MapCell的接口的實現並向World Entities提供所需的內容。

根據您獲得MapCell的方式，使用您選擇的IoC來提供實施，您可能還需要在工廠上分層。

沒有您的特殊需求的更多細節，它很難具體，但我認爲這種方法一般應該是可行的。

Answer 2

讓不同名稱空間中的類在細粒度級別上進行交互沒有任何問題。關注點的分離可以在訪問者保護級別（公共，受保護，私人等）下完成。您可以在邏輯或結構上將項目分解爲子項目，應用您認爲相關的任何額外的組織限制。

一些策略可能是：

• 結構上分離的邏輯，其中每個筒倉恰巧住在自己建立的命名空間，只有通過高層次的接口進行交互。
• 邏輯分離，其中一個程序集（或一組asms）成爲可跨越多個名稱空間的邏輯項目。交互可以通過接口完成，但也可以通過充分考慮成員訪問來完成。

要解開它們，嘗試從不同的角度看項目。從一個POV看起來像是一團糟的東西，實際上可以從另一個POV看起來優雅。如果你發現它們的類結構實際上有一個合理的邏輯，可能所有需要的就是開始將零件和零件分離成不同的程序集，只需稍微調整一下命名空間即可。如果你發現它確實是混亂的，那麼你的工作對你來說是截然不同的：-D

Answer 3

1. 分而治之設計建議你應該分開UI和核心組件。
2. 你的遊戲邏輯應該是核心模塊而不是UI的一部分。
3. 用戶界面應該有圖形界面和操作界面或對象行爲界面，並由核心模塊實現。