C# 关于Unity3D实体SRP的建议

我目前正在Unity3D中制作一个游戏，并在学习的过程中尝试将SOLID的单一责任原则应用到我的游戏中

我想知道是否有人可以解释一下SRP的良好实现是什么样子的，因为我觉得我正在破坏它

我已将我的课程分为基本部分：

• PlayerInput.cs-获取输入并将其存储到变量中（水平、垂直、RMB等）
• PlayerController.cs-处理攻击和玩家状态（空闲、移动、攻击）
• PlayerMovement.cs-处理移动和旋转（查看鼠标）
• AnimationController.cs-处理所有动画

当我开始的时候，我觉得我在遵循SRP，但现在游戏变得越来越复杂。上面列出的每个类都会引用其他类，这似乎是不必要的。我在每个类中使用了5个GetComponents，这似乎是重复的，因为它们都在同一个对象上。换句话说，SRP似乎需要更多的工作，并且正在降低效率

例如，PlayerController和PlayerMovement脚本都引用了AnimationController，其中AnimationController也引用了这两个脚本。所有脚本都有对PlayerInput的引用。（请记住，我省略了其他与玩家相关的脚本，如制作和装备，以保持简单，但我的Start和Awake方法充满了一堆GetComponent调用）

有谁能更好地向我解释SRP，也许能给我指出正确的方向，这样我就不会在同一个游戏对象上使用太多GetComponent了

---

谢谢

听起来你所指的与SRP无关。SRP最基本的意思是，您拥有的任何类都应该只对一件事“负责”。您的

PlayerInput

负责跟踪播放机通过其接口设备提供的内容，

PlayerController

根据许多因素提供有关播放机的有状态信息，等等

你所指的似乎更多地与干燥（不要重复自己）原则有关。DRY很好，它为抽象和代码重用提供了一个很好的主干，但它不是福音。事实上，其中一个坚实的原则——依赖倒置原则——在某种程度上积极鼓励人们以灵活性的名义重复自己

如果你认为调用方法太多，你可以考虑在该方法中封装一系列调用和其他方法中的任何交互逻辑，并调用它。当然，这取决于需要在多个位置调用的同一组指令

现在，我要说的是，您的帖子中跳出的一部分是

AnimationController

和

PlayerController

以及

PlayerMovement

类之间的循环引用。这实际上违反了SRP和其他一些良好设计原则，因为封闭的类现在负责分配给它们的任务，并且至少跟踪

AnimationController

中发生的事情，最多调用

AnimationController

本身的方法

---

你应该考虑重构你的更细粒度的类，这样他们就可以完成他们的工作，不管在< AnimationController > <代码>中发生了什么，反之亦然。封闭类应该处理逻辑来告诉封闭类该做什么，本质上是为封闭类做决定。

您已经正确地识别了问题，这显然需要解决，无论理论原理如何。但好的，让我们先讨论SRP：

SRP引用了两个较老的概念，即耦合和内聚。不幸的是，“SRP”这个名字令人困惑，模棱两可，而且只包含了等式的一面，那就是拆分内容。它没有提到那些属于一起的东西实际上应该在一起

因此，所有这一切的目的是为了实现可维护性，这是减少未来工作的简写。要做到这一点，相互关联的事物实际上应该在一起似乎是合理的。这意味着处理某些数据的方法应该与该数据位于同一位置（即，在同一对象中）。松散相关的内容（即很少相互引用）应拆分

在实践中如何做到这一点取决于商业案例，并不总是显而易见的。我建议做个运动。将这些东西放在一个类中，例如称之为

Player

。简化它，删除所有setter/getter和间接寻址。然后试着看看是否有一些区域只是松散地相互引用，或者只在一个方向引用。这些都是很好的人选

试着把有意义的东西分开，而不是技术上的东西，例如

移动

，

攻击

，

播放器

都是好的，

控制器

，

动画

都是有问题的（尽管并不总是坏的）