关于 Unity3D SOLID SRP 的建议答案

【问题标题】：Advice on Unity3D SOLID SRP关于 Unity3D SOLID SRP 的建议
【发布时间】：2019-08-11 07:27:36
【问题描述】：

我目前正在使用 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。

谢谢

【问题讨论】：

标签： c# unity3d solid-principles single-responsibility-principle

【解决方案1】：

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

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

所以这一切的重点是启用可维护性，这是减少未来工作量的简写。为此，指称彼此的事物实际上应该在一起似乎是合理的。这意味着处理某些数据的方法应该与该数据位于同一位置（即在同一个对象中）。松散相关（即很少相互引用）的东西应该分开。

在实践中如何做到这一点取决于业务案例，并不总是显而易见的。我建议做一个练习。将这些东西放在一个类中，例如称为Player。简化它，删除所有 setter/getter 和间接。然后尝试查看是否存在仅松散地相互引用的区域，或者仅在一个方向上引用。这些将是分裂的好候选人。

尝试拆分有意义的事情而不是技术性的事情，即Movement、Attack、Player 都很好，Controller、Animation 是有问题的（尽管并不总是坏的）。

【讨论】：

【解决方案2】：

听起来您所指的内容与 SRP 无关。在最基本的情况下，SRP 意味着您拥有的任何课程都应该只对一件事“负责”。您的PlayerInput 负责跟踪玩家通过其接口设备提供的内容，PlayerController 基于多种因素提供有关玩家的状态信息，等等。

您所指的似乎与 DRY（不要重复自己）原则更相关。 DRY 很棒，它为抽象和代码重用提供了一个很好的支柱，但它不是福音。事实上，SOLID 原则之一——依赖倒置原则——在某些方面积极鼓励人们以灵活性的名义重复自己。

如果您认为您过多地调用一个方法，您可以考虑将对该方法的一系列调用和任何中间逻辑封装在另一个方法中，然后调用它。当然，这取决于需要在多个地方调用的同一组指令。

现在，我要说的是，您的帖子中跳出的一部分是您的AnimationController 和您的PlayerController 和PlayerMovement 类之间的循环引用。这实际上违反了 SRP 和其他一些良好设计的原则，因为封闭的类现在负责分配给他们的任务，并且至少跟踪正在发生的事情在AnimationController 中，最多调用AnimationController 本身的方法。

您应该考虑重构更细化的类，以便无论AnimationController 中发生什么，它们都能完成工作，反之亦然。封闭类应该处理告诉封闭类做什么的逻辑，本质上是为封闭类做出决定。

【讨论】：