我想知道拆分编辑器和构建逻辑的最佳实践是什么。 （编辑器类、部分类）
我说的是像 OnDrawGizmo() 和 OnValidate() 这样的移动函数。感觉所有这些逻辑都不应该写在同一个 MonoBehaviour 中。
创建编辑器脚本也感觉不对，因为您需要为要调试的任何私有数据创建 getter。
部分类是否可以解决这个问题，以及业界是否遵循任何方法。 （部分类的开销是否很大）
很想在这里找到这个问题的任何其他解决方案，有时我有点完美主义者，我知道将它们留在同一个文件中可能是可以的。
因为这个问题更多的是讨论，并根据意见得出答案。我会保持简短和客观。
在编辑器中，您有多种编辑器逻辑替代方案，例如：
在资产文件夹中，您可以创建一个编辑器文件夹，该文件夹允许您创建仅限编辑器的脚本，这些脚本在构建时不会包含在可执行文件中。此选项非常适合编辑器窗口或某些不需要与类的内部工作直接通信的特定于编辑器的逻辑。
使用分部类非常适合在不使用反射的情况下向编辑器公开类的其他隐藏成员。然而，它确实给开发人员带来了繁重的工作，无论何时他们执行编辑器逻辑，都要记住使用定义门UNITY_EDITOR，而且还要排除仅编辑器的命名空间，这会导致构建错误。
如果您愿意，可以随意为编辑器创建部分类或单独的实用程序脚本。这些函数只是调试和方便的工具。它也可以在大多数 IDE 中折叠，甚至可以分为Region定义。
#region EditorStuff
private void OnDrawGizmos(){}
#endregion
使用你需要的东西，有很多选择和意见可以使用或不使用某些设计理念。我个人的看法是使用你需要的东西，而不是别人强迫你使用的东西，除非工作或学校的编码标准另有规定。但我们的想法是，所有的设计理念都在你的工具箱中，但你可以决定工具箱中的哪种工具最适合你面临的问题。也许是它的多态性，也许是它的策略模式，也许是它的函数式编程。您可以使用哪种工具由您决定，编辑器和游戏逻辑是否应该抽象为单独的类也是如此。答案是：这取决于