擁有更多的Java類或者擁有更少的類來完成更多的工作會更好嗎？

我目前正在製作遊戲。目前，我有一個職業（遊戲環境），負責持有遊戲對象（敵人，武器等）的集合，並進行碰撞檢查，調用對象的創建例程等。隨着我的進步項目中，我開始懷疑是否應該採用更多層次的方法 - 比如擁有一個WeaponsManager，一個EnemiesManager和一個將所有東西放在一起的Environment，或者讓我的Environment類操作每個對象，現在正在做什麼？擁有更多的Java類或者擁有更少的類來完成更多的工作會更好嗎？

它可能提的是，遊戲中的對象已經相當嚴重分層的價值：

BaseClass 
-----EnemyClass 
----------Enemy1Subclass 
----------Enemy2Subclass 
-----WeaponClass 
----------Weapon1Subclass 
----------Weapon2Subclass

BaseClass的有定義的基本對象的屬性，如位置。 EnemyClass和WeaponClass是相當通用的類，它們定義了更多的特定於類的方法和屬性，例如EnemyClass的速度或WeaponClass的損壞。它們大多存在，所以我可以擁有相當通用的集合，而不是爲每個敵人/武器類型單獨收集。 Enemy1Subclass/Enemy2Subclass和Weapon1Subclass/Weapon2Subclass是實際創建和使用的敵人/武器類。

我的Environment類存儲EnemyClass/WeaponClass的集合，並通過調用遊戲對象的方法進行必要的操作。

Environment (manipulates EnemyClass and WeaponClass objects by iterating over their respective arrays and calling their respective methods; doesn't do any subclass-specific stuff) 
-----EnemyClass array 
----------Enemy1Subclass entry 
----------Enemy2Subclass entry 
----------Enemy1Subclass entry 
-----WeaponClass array 
----------Weapon1Subclass entry 
----------Weapon2Subclass entry 
----------Weapon2Subclass entry

但現在我想知道如果分離的另一個層將是一個不錯的主意，與環境保持EnemyManager/WeaponManager類和相應的管理人員持有和操作自己的藏品：

Environment (calls generic instantiation, destruction, moving, etc. methods in EnemyManager and WeaponManager; doesn't ever directly interact with an EnemyClass or WeaponClass object) 
-----EnemyManager (gets instructions from Environment and manipulates EnemyClass objects to carry out those instructions) 
----------EnemyClass array 
---------------Enemy1Subclass entry 
---------------Enemy2Subclass entry 
---------------Enemy1Subclass entry 
-----WeaponManager (gets instructions from Environment and manipulates WeaponClass objects to carry out those instructions) 
----------WeaponClass array 
---------------Weapon1Subclass entry 
---------------Weapon2Subclass entry 
---------------Weapon2Subclass entry

思考？建議？我無法找到任何關於這種「更多班級或更難工作的班級」的會議，所以任何答案都是公平的遊戲，直到幷包括「你的模型是垃圾，重新開始」。雖然希望它不會來。 ;）

來源

2013-04-10 computerfreaker

可以適用於http://programmers.stackexchange.com/或http://codereview.stackexchange.com/ – rajesh 2013-04-10 05:34:59

最好的標記，因爲我認爲這是一個值得商榷的問題。這個國際海事組織沒有好的答案。但是您應該考慮閱讀設計模式書籍，以便您瞭解適合您的域名或問題的更適合的內容。 – 2013-04-10 05:47:36

一般來說（非常普遍），面嚮對象語言的一個主要優點是封裝 - 的想法，最好是將相關的函數/方法和數據一起（在適當的權限）。在這裏應用，這意味着只要「有意義」就可以更好地分離代碼。在你的例子中，「較難工作的班級」意味着班級規模較大，整體難以理解，處理大量數據。涵蓋連續兩側的兩個漂亮的準則：

如果您需要跟蹤的是一個類的內部發生的一切的流程，你應該讓另一個類
如果您發現A類僅包含僅包含方法C的B類，也許這可以全部在一個函數內

總之，盡你所能確保你的代碼在合理而不是多餘的部分被分開。

來源

2013-04-10 05:45:04 WannabeCoder

我的Environment類有554行;其中很大一部分是對象操作，可以很容易地將其分解爲另一個或兩個類。你的流程評論爲我決定了一些事情（我還沒有完全意識到我的環境有多複雜！） – computerfreaker 2013-04-10 06:06:54

請記住，在（幾乎）所有的編程中，清晰度都是關鍵。

在這種情況下，做一下最直觀的做法。我發現，將程序和函數拆分爲多個類通常是值得的，因爲它提高了可維護性，並使代碼更加明確。

然而，syntactic sugar和syntactic saccharin之間的細線。換句話說，儘可能使組織保持整潔，但不要過分。做什麼使你的代碼變得最清晰。

在這種情況下，這似乎是interface s的一個很好的用法。嘗試在創建接口或抽象類的新實例時避免instanceof。

來源

2013-04-10 05:35:33 Zyerah

我實際上認爲抽象類可能比BaseClass的接口更好，因爲一些行爲在所有類中都是相同的（即定位約束和定位），而另一些則是類特定的。我的理解是，一個接口不能在抽象類可以實現這些交叉類方法的情況下實現，並且這兩個方法都可以針對特定於類的行爲繼承。我只能使用兩個instanceof操作符，使用一堆重載的方法，並將Enemy1Subclass/Enemy2Subclass中的某些邏輯移入EnemyClass，以使其更通用。 – computerfreaker 2013-04-10 05:45:34

@ user2245528這可能是。如果不熟悉項目的設計和佈局，我不能確定地說，但聽起來您正處於正確的軌道。 – Zyerah 2013-04-10 05:46:58

儘管在開始黑客行爲之前先考慮一下架構是一件好事 - 將編程視爲一個迭代過程。因此，從最簡單的事情開始，然後不斷重構。這樣你就不會過度使用並保持代碼的可維護性。因此，關於您的文章標題，請先從一個班級開始工作，如果您想提取某些內容是有意義的，那麼做 - 現在的IDE會讓您變得非常容易。

來源

2013-04-10 05:42:43

擁有更多的Java類或者擁有更少的類來完成更多的工作會更好嗎？

回答

相關問題