Partial classes for custom editors... a useful concept?

Unity Engine
1

As many know, when using C# it is possible to define partial classes and methods (at least, when compiling to DLLs).

With time my custom ‘Editor’ class has become quite large since it contains both inspector-specific and scene-specific logic. I have used regions to help keep the code organized. But, with a little experiment I have found that the following seems to work quite well.

I haven’t decided whether I am going to run with this yet, but I was wondering what others thought about this:

FancyThing.cs

using UnityEngine;

public class FancyThing : MonoBehaviour {
    public int test;
}

Editor/FancyThingEditor.cs

using UnityEngine;
using UnityEditor;

[CustomEditor(typeof(FancyThing)), CanEditMultipleObjects]
partial class FancyThingEditor : Editor {

    partial void OnInspectorEnable();
    partial void OnSceneGUIEnable();

    private void OnEnable() {
        OnInspectorEnable();
        OnSceneGUIEnable();
    }

}

Editor/FancyThingInspector.cs

using UnityEngine;
using UnityEditor;

partial class FancyThingEditor {

    private SerializedProperty testProp;

    partial void OnInspectorEnable() {
        // Inspector-specific preparation.
        testProp = serializedObject.FindProperty("test");
    }

    public override void OnInspectorGUI() {
        serializedObject.Update();

        EditorGUILayout.PropertyField(testProp, new GUIContent("Test"));

        serializedObject.ApplyModifiedProperties();
    }

}

Editor/FancyThingSceneGUI.cs

using UnityEngine;
using UnityEditor;

partial class FancyThingEditor {

    partial void OnSceneGUIEnable() {
        // Scene-specific preparation.
    }

    private void OnSceneGUI() {
    }

}
2

If Unity isn’t raging about partial, class name vs file name… Good. Do whatever you want.

Frankly, I haven’t got a class that is so big that I want to split it in partial file… yet.

3

Having gone down the same path in a time crunch on a past project, my suggestion is to take a different approach. Regions in C# were a big mistake; they just make it tempting to create an unmanageable monster class, as do partial classes. Partial classes should generally only be used when part of your class is hand-written and the other is machine-generated.

Perhaps there’s a way to simplify your class by dividing functionality into subclasses. Each subclass is then smaller, more focused and manageable, and less prone to bugs or side effects. This also usually lets you test individual subclasses independently so you can be sure they work before you put them all together.

If you can generalize the functionality of a subclass, it’s even better for code re-use (i.e., Don’t Repeat Yourself). For example, say your editor has a graphical node-based canvas. Rather than implementing node drawing and input handling in your editor class, you can put the code in a parent class or utility class. Then you can also re-use this code for other node-based editors. This is an obvious example, but even when it seems like you’d only use the code in one place, it’s still worth doing to keep classes small and maintainable.

Of course, as LightStriker says, do whatever you want. These are just my experiences.

4

I think that you are right… this would definitely be a cleaner approach.

I totally agree with your point regarding partial classes, they do make better sense to separate automated code generation from user implementation.

Thanks for your input :slight_smile: