A completely trivial subject coming up next…triggered by a really interesting debate I was involved with the other day. When dealing with class hierarchies and chaining constructor arguments through this hierarchy, what’s our mindset as to the direction of travel? Do we think of passing arguments ‘up’ or ‘down’ the hierarchy of objects (initially anyway, before any other classes constructors in the chain are called in the opposing direction)? The direction of travel, granted, is totally inconsequential and we’re dealing with a non-concrete concept anyway, but it seems like fun to debate it so why the hell not!
I’ve always thought of constructor arguments being chained ‘up’ to the ‘base’ class; which is where we hit the area that causes conceptual confusion. It was debated that a ‘base’ class ‘underpins’ something and sits as a stabilising entity at the ‘root’ (i.e. the bottom of a pyramid, the roots of a tree, foundations of a building, etc.). This is an argument that seems to make a lot of sense and made me wonder if I’d been inverting this in my head all along. There seemed to be a split amongst us about the direction of travel, which turned out to be a good laugh to be fair!
So, the word ‘base’ – it certainly does lend some weight to the idea that we should be visualising our way travelling down, even though I’ve always thought of flying my way upwards in this regard! I decided to see what I could find, to answer what is (most likely) the most non-sensical and unimportant of questions!
1) A poor man’s Google image search for ‘object inheritance example’:
There are some interesting things going on here, just from a visual perspective. Classic inheritance (X ‘is a’ Y) appears to show the ‘base’ class at the top of (or in a spatial sense, above other ‘nodes’) most object hierarchies; this is where I would always term a base class as a parent class. You can also see the odd example of the containment/delegation model on show (X ‘has a’ Y) with objects shown to the side of the referencing class (now we have to think about left and right! 🙂 ).
2) Blogs and Wiki:
The above two resources again show a hierarchy configuration with the parent class being above inheriting (or derived classes) – This is how I’ve always viewed it. Sub-classes inherit from the parent class, like a family tree; this is where you consider a parent class as a family predecessor (like a Grandfather), with sub-classes inheriting traits (genes), like classes that represent the Father and subsequent Child. Therefore, passing of constructor arguments, in my head, occurs in an upwards direction (from the Child back towards the Grandfather).
3) Good Old Fashioned Book:
The next source is a good old fashioned book (a really great one, by the way): Pro C# 7: With .NET and .NET Core.
Again, the terms ‘parent’ class are substituted frequently for ‘base’ and when inheritance is discussed derived classes are denoted as ‘sub-classes’ or ‘children. These are always visualised with the parent/base class being shown at the top of the hierarchy tree. My mindset has always followed the logic outlaid here:
Constructor chaining occurs through the use of inheritance. A sub-class constructor method’s first task is to call its superclass’ constructor method. This ensures that the creation of the subclass object starts with the initialization of the classes above it in the inheritance chain.
4) Default behaviour of a Class Diagram:
Lastly, what does a standard class diagram look like if you drag and drop a set of related classes on to it (Enemy being the top level superclass, with Blob and Green Blob being descendants):
In this instance, the Enemy ‘base/parent’ class is shown at the top of the diagram with it’s derived classes below it. When a Green Blob is created we are chained through Blob to Enemy (via the ‘base’ keyword) in the first instance to instantiate the Enemy class members first – did we go up or down to get there, that is the question (and are we going up or down when each sub-classes constructor is called, in turn 😉 )?
So, from a hierarchical perspective, should we illustrate diagrams with a ‘base’ class ‘above’ or ‘below’ it’s derived class? Or perhaps the debate lies in the semantics of how the process works? It could just be however the particular developer is wired in regards to how they see hierarchies in their own minds.
Everything I see (visually and from every resource I seem to pick up) seems to back up my initial idea that constructor arguments should be considered to be chained ‘up’ through the hierarchy to a parent class (as opposed to chained ‘down’ to the parent class), but it doesn’t hold true to everyone (with the classic debate over the word ‘base’, suggesting something lurking at the ‘root’); Perhaps my mind is slightly warped! Is there an answer, I don’t know. Does it matter to anyone, again I’m not sure! Has it been a waste of a few hours on a Saturday, almost certainly!
I did have a good search for constructor chaining in relation to going ‘down’ and it does come up, but only in regards to overloading constructors and chaining calls on a singular object (not inheritance-based). I couldn’t see an object hierarchy illustrated with the base class at the, um, base (as a bottom node) – but it could well be out there! If anyone else fancies chipping into a debate that probably has never been once asked for (ever!) then feel free to pitch in a comment below, I’d love to hear from you. Cheers all and happy coding!
bearandhammer 