我目前正在用Unity3D制作游戏，并在学习游戏时尝试将SOLID的单一职责原则实施到我的游戏中。
我想知道是否有人可以解释一下SRP的良好实现是什么样子，因为我觉得自己正在打破它。
我将我的课程分为基础部分：
PlayerInput.cs-获取输入并将它们存储到变量中（水平，垂直，人民币等）
PlayerController.cs-处理攻击和玩家状态（空闲，移动，攻击）ATM
PlayerMovement.cs-处理移动和旋转（查看鼠标）
AnimationController.cs-处理所有动画
当我开始的时候，我觉得我正在遵循SRP，但是现在游戏变得越来越复杂。上面列出的每个类都有对其他类的引用，这似乎是不必要的。我在每个类中使用了5个GetComponents，但由于它们都在同一对象上，因此似乎是重复的。换句话说，SRP似乎需要更多工作，并且使其效率降低。
例如，PlayerController和PlayerMovement脚本都引用了AnimationController，而AnimationController也引用了两者。所有脚本都引用了PlayerInput。 （请记住，为了简化起见，我省去了其他与玩家相关的脚本，例如工艺和设备，但我的Start和Awake方法充满了GetComponent调用。）
谁能更好地向我解释SRP，也许可以向我指出正确的方向，所以我在同一个GameObject上使用的不是GetComponent。
谢谢
最佳答案
您已经正确识别了问题，无论理论原理如何，显然都需要解决该问题。但是，让我们首先讨论SRP：
SRP引用了两个较旧的概念，即耦合和内聚。不幸的是，名称“ SRP”令人困惑，模棱两可，并且仅包含等式的一侧，即拆分内容。它没有提到属于一起的东西实际上应该在一起。
因此，所有这些的重点是实现可维护性，这是减少将来工作量的捷径。为此，相互参照的事物实际上应该在一起是合理的。这意味着使用某些数据的方法应与该数据位于同一位置（即在同一对象中）。松散相关的资料（即彼此很少提及）应该分开。
实际上，如何执行此操作取决于业务案例，并且并不总是很明显。我建议做运动。将这些内容放在一个类中，例如，将其称为Player。简化它，删除所有的setter / getter和间接方法。然后尝试查看是否存在仅松散地互相引用或仅在一个方向上引用的区域。这些将是很好的候选人。
尝试将有意义的东西而不是技术性的东西分开，即Movement，Attack，Player都是好东西，Controller，Animation是可疑的（尽管并不总是坏的）。
关于c# - 关于Unity3D SOLID SRP的建议，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/57448104/