I’m confused. I have seen a plethora of source that does this but I’m confused as to why it is done and if it is even efficient to implement.
So, what benefits does this give?
Your thinking here is backwards. A MonoBehavior is a special, cumbersome thing that is only useful in a specific context. It’s for when you need the Unity game engine to invoke your code according to the various Unity callbacks such as Awake, Start, Update, etc… and when you need to associate your code with a GameObject in the game world. When you’re not doing any of that, you can use a plain old streamlined C# class that doesn’t have the baggage or limitations of a MonoBehavior. MonoBehaviors can only be created via the Unity engine (e.g. loaded from a scene or Instantiated) and cannot exist without a GameObject. Their lifecycle is bound inextricably to that GameObject. Plain C# objects don’t have those limitations.
By the way your title here is a bit ambiguous. Are you talking about defining inner classes, or just having references to non-MonoBehaviours in MonoBehaviours?
2 Likes
Both, I think.