A short note on using Object Oriented models in Unity

In the last weeks as a part of my learning Unity development I have been exploring how to integrate object oriented programming (OOP) modeling concepts in Unity, as done in projects such as in those by Brett Hewitt, Unity 4.x Game AI Programming,  in the Unity examples and in others created by friends. Given what a nice and evolved language is C#, the temptation of projecting the OOP techniques I’m used to in Java is irresistible.

One useful answer to a “root” doubt I got it here:

OOP for Unity

But my impression was more and more that I simply had to drop my “start modeling from the root” approach (coming from server side web development) as wrong, and now the point has become clear: in Unity you simply don’t begin at the top of the object hierarchy, not even closer: you begin at the bottom! MonoBehaviour is neither an interface nor an abstract class, but as concrete as it can be, handling e.g two timelines and a series of extension by components. The correct way is to use a component based approach, just like MonoBehaviour does, where your MonoBehaviour (flat, direct, and final) extensions instances can carry modeling properties which can use inheritance modeling.

Happier now Sorriso

Social Share Toolbar

Comments

  1. I definitely agree, and tend to use a component-based approach all over the project. Still, I prefer to extend MonoBehaviours that need to do stuff when destroyed (and that as such need to implement a Destroy method that is also called during OnDestroy), and thus usually keep an abstract DestroyableMonoBehaviour class around to inherit from, so that all the correct operations are carried on.

Speak Your Mind

*