Unity MonoBehaviour對象vs遊戲邏輯

Question

我最初在昨天發佈了這個Unity應答論壇，但還沒有得到任何迴應。所以我想我會在這裏嘗試我的運氣。

所以我對Unity有些不高興。自從Unity 3以來，我一直在討論它，但實際上從未做過任何建設性的或值得一提的事情。在我的計算機科學專業畢業後，我從事C＃，ASP.NET和JAVA程序員已經超過5年。所以我想扔掉那裏，我明白OOP。所以，打我這裏的硬道理。

我的問題是這樣的，我想創建的類層次時，需要了解標準的做法，他們應該如何擴展或扎入MonoBehaviour類。

這是我在一個層次結構特殊情況：

IPickupable (interface) > Item : Monobehaviour, IPickupable > Weapon : Item, IEquipable (interface) > Sword : Weapon 

這是我現在有。我將MonoBehaviour放在我的類結構的最底層，這樣當我創建一個新的Sword（）對象時，我必須使用Start（）。

我感到困惑的問題，就是到處看，說你不應該在你的班級，從MonoBehaviour獲得使用構造函數。那麼，當我創建我的數據庫中的項目字典時，我想創建一堆劍的實例，並將它們存儲在一個集合中。這一切都發生在代碼中，實際上並沒有在屏幕上呈現或在遊戲中發生。

難道更有利於建立自己的階級結構，使得所有的遊戲邏輯包含正常班內 - 然後有一個使用我的最頂端邏輯類頂層類。例如，我上面的例子將改變這樣的事情：

SwordObject : Monobehaviour 
private Sword sword; 

這樣，我將被連接到一個遊戲物體實際腳本仍然可以訪問所有的劍方法和數據成員，但我可以隨時隨地實例化類。

我目前對如何去這個惡魔戰鬥，並以爲我會看看是否有遊戲邏輯和團結更多的有經驗的程序員可以幫助我的一些最佳實踐。我是一名商業邏輯程序員，每天只處理會計問題，API，移動開發和網頁設計，所以遊戲邏輯對我來說都是新的。感謝您的幫助，見解，建議和反饋！

Answer 1

我很困惑的問題，無處不在我看，指出你不應該在派生自MonoBehaviour的類中使用構造函數。

Unity期望充當從UnityEngine.Object繼承的所有對象的工廠，其中包括所有GameObjects，組件，行爲腳本等。

在許多情況下，與你互動的.NET對象更多的是墊片的底層C這實際上使用的引擎++對象。直接調用其中一個構造函數將創建一個.NET對象，該對象從其C++內部元件中孤立出來。

所有這一切都被隱藏起來，使團結就是初學者更容易獲得。他們不會說「嗨，用這種工廠模式來構建組件」，他們會告訴您致電AddComponent。只要讓Unity處理這些對象的初始化，所有這些都是（大部分）透明和無縫的。

所以，這聽起來像你正在考慮創建一些POCO類來存儲配置數據。這很好 - 我一直都在這樣做。只要確保你保持你的類和Unity原生類之間的分離。