I’m a self taught programmer who is still trying to get a grasp on “well designed code” while also trying to get work done and shipped. I’m currently working on a few VR and Hololens projects, and I was struck by the “complexity” of the HoloToolkit-Unity, Microsoft’s API for working with the Hololens.
In a years time, it went from a simple interface to quite a substantial library. The amount of interfaces and indirection is something I’m still trying to get my mind around.
My question is is how “typical” is this code architecture in most game development? Is it typical to have this amount of inheritance?
What are some good strategies for formulating this sort of architecture?
Honestly, I’m not seeing that much inheritance here.
We’ve got what:
BaseInputSource, and 3 concrete Input classes that inherit from it.
BaseEventData to define generic event data, and BaseInputEventData inheriting from that for generic input event data, and than a handful of concrete input event data types for various events.
The rest of the classes seem to inherit MonoBehaviour or Singleton (which I presume is just a Singleton Monobehaviour).
Design patterns…
I mean, honestly this structure above is pretty straightforward.
We have various observer contracts with the interfaces. A smattering of singletons. Our input classes may inherit from some base input type… but really that complexity is really on the same level as the interface contracts. The only robust inheritance chain is probably the eventdata, and even then that’s a fairly common eventdata structure. Similar to unity’s one eventdata, or EventArgs from within .net. You usually have a base ‘eventdata’ type so that way you can generically react to events with out needing specialized methods.
For example if I wanted to do the same thing in both a ‘hold’ event and a ‘manipulation’ event regardless of which one it is… why have 2 distinct ones that take ‘HoldEventData’ and ‘ManipulationInputEventData’ parameters… when I could just have one listener method that takes ‘BaseEventData’.
If you want to discuss design patterns or something… well you should start out by reading about some of them: http://www.oodesign.com/
Then maybe come back here and ask some more specific questions. Some of us would be happy to help out.
I guess I’m trying to wrap my mind around when you “should” have a nice hierarchical structure and when not too. The EventData hierarchy is cool and after thinking about it, makes sense. But the Cursor and InputManager are fairly large. I guess I’m trying to get a sense of when one should break up a large class into smaller ones. Granted, I work by myself mostly or with a few other individuals. The API structure here is designed to be super flexible for thousands of people. I suppose that’s a factor.
It’s interesting to compare where the state of this API was last year as it was dirt simple then.
Love the art style of your “How Now, Sea Cow?” I’m a sucker for that type of art.