我目前正在 Unity3D 中制作游戲，并在學習過程中嘗試將 SOLID 的單一職責原則應用到我的游戲中。我想知道是否有人可以更多地解釋一下 SRP 的良好實施是什么樣子，因為我覺得我正在破壞它。我將我的課程分為基礎部分：PlayerInput.cs - 獲取輸入并將其存儲到變量中（水平、垂直、人民幣等）PlayerController.cs - 處理攻擊和玩家狀態（空閑、移動、攻擊）ATMPlayerMovement.cs - 處理移動和旋轉（看看鼠標）AnimationController.cs - 處理所有動畫當我開始時，我覺得我遵循的是 SRP，但現在游戲變得越來越復雜。上面列出的每個類都會引用其他類，這似乎是不必要的。我在每個類中使用了大約 5 個 GetComponents，這似乎是重復的，因為它們都在同一個對象上。換句話說，SRP 似乎需要更多工作，并且降低了效率。例如，PlayerController 和 PlayerMovement 腳本都有對 AnimationController 的引用，其中 AnimationController 也有對兩者的引用。所有腳本都有對 PlayerInput 的引用。（請記住，為了保持簡單，我省略了其他與玩家相關的腳本，例如制作和裝備，但我的 Start 和 Awake 方法充滿了一堆 GetComponent 調用）誰能向我更好地解釋 SRP，并可能為我指明正確的方向，這樣我就不會在同一個 GameObject 上過多地使用 GetComponent 了。
2 回答
一只名叫tom的貓
TA貢獻1906條經驗 獲得超3個贊
您已經正確地識別了問題，無論理論原理如何，這顯然都需要解決。但好吧，我們先討論 SRP：
SRP 引用了兩個較舊的概念，即耦合和內聚。不幸的是，“SRP”這個名字令人困惑、含糊不清，并且只包含等式的一方面，即分割東西。它沒有提到屬于在一起的東西實際上應該在一起。
因此，這一切的目的是實現可維護性，這是減少未來工作的簡寫。要做到這一點，相互引用的事物實際上應該在一起似乎是合理的。這意味著處理某些數據的方法應該與該數據位于同一位置（即在同一對象中）。松散相關的內容（即很少互相引用）應該分開。
在實踐中如何做到這一點取決于業務案例，并且并不總是顯而易見的。我建議做一個練習。把這些東西放在一個類中，稱之為Player例如。簡化它，刪除所有 setter/getter 和間接。然后嘗試查看是否存在僅松散地相互引用的區域，或者僅在一個方向上引用的區域。這些將是很好的候選者。
嘗試分割有意義的東西而不是技術性的東西，即，，，Movement都是好的，，，都是有問題的（盡管并不總是壞的）。AttackPlayerControllerAnimation
紅糖糍粑
TA貢獻1815條經驗 獲得超6個贊
聽起來您所指的內容與 SRP 無關。從最基本的角度來說，SRP 意味著您擁有的任何類都應該只“負責”一件事。您PlayerInput負責跟蹤玩家通過其接口設備提供的內容，PlayerController根據多種因素提供有關玩家的狀態信息，等等。
您似乎指的是與 DRY（不要重復自己）原則更相關。DRY 很棒，它為抽象和代碼重用提供了強大的支柱，但這并不是福音。事實上，SOLID 原則之一——依賴倒置原則——在某種程度上積極鼓勵人們以靈活性的名義重復自己。
如果您認為對某個方法的調用過多，則可以考慮將對該方法的一系列調用以及任何中介邏輯包裝在另一個方法中，然后調用該方法。當然，這取決于需要在多個位置調用同一組指令。
現在，我要說的是，您的帖子中跳出的一部分是您的AnimationController和 、PlayerController和PlayerMovement類之間的循環引用。這實際上違反了 SRP 和其他一些良好設計的原則，因為封閉的類現在負責分配給他們的任務，并且至少跟蹤 中發生的事情，并且在最開始的時候AnimationController。大多數，調用自身的方法AnimationController。
您應該考慮重構更細粒度的類，以便無論發生什么情況它們都能夠完成自己的工作AnimationController，反之亦然。封閉類應該處理告訴封閉類要做什么的邏輯，本質上是為封閉類做出決定。
- 2 回答
- 0 關注
- 136 瀏覽
添加回答
舉報
0/150
提交
取消