Using partial classes for MonoBehaviours to split editor and build logic?

Question

I'm wondering what the best practice is for splitting editor and build logic. (Editor Classes, Partial Classes)

I'm talking about moving functions like OnDrawGizmo() and OnValidate(). It doesn't feel write for all this logic to be in the same MonoBehaviour.

It also doesn't feel right creating an editor script, because you are there required to create getters for any private data you want to debug.

Would partial classes be a solution to this, and it there any approach that is followed in the industry. (Is there any heavy overhead of partial classes)

Would love to here any other solutions to this problem, sometimes i'm a bit of a perfectionist and I understand it's probably okay to leave them in the same file.

Answer 1

Since this question is more of a discussion and yields answers based on opinions. I'll keep myself short and objective.

In the editor you have numerous alternatives for Editor logic such as:

• Editor only monobehaviours
• Monobehaviours containing Editor only logic
• EditorWindow
• MenuItems
• etc etc (you can read more here under the UnityEditor)

First Approach

In your assets folder, you can create a Editor folder, which will allow you to create Editor only scripts which won't be included into the executable when building. This option is perfect for a editor window or some verry editor specific logic that doesn't need direct communication with the inner workings of a class.

Second Approach

Using partial classes are great for exposing otherwise hidden members of a class to the editor without using reflection. It does however put taxing work on the developers to always remember to use define gates UNITY_EDITOR whenever they do editor logic, but also to exclude editor only namespaces, which would result in build errors.

OnDrawGizmos and OnValidate

Feel free to create partial classes or separate utility scripts for the editor if you like. These functions are simply tools for debugging and convenience. Which also can be collapsed in most IDE's and even separated into a Region defines.

#region EditorStuff
   private void OnDrawGizmos(){}
#endregion

Some wise words

Use what you need, there are alot of options and opinions out there for using and not to use certain design philosophies. My personal take is to use what you need, and not what others forces you to, unless coding standards at work or school says otherwise. But the idea is that all the design philosophies out there are tools in your toolbox, but its up to you to decide what tool in your toolbox is most suitable to the issue you have before you. Maybe its polymorphism, maybe its strategy patterns, maybe its functional programming. Which tool you may use is up to you to decide, the same goes for if Editor and Game logic should be abstracted into separate classes or not. And the answer is: It depends