We switch gears in this episode and start to look at inheritance. This is a core feature of object-oriented design and the most recognizable attribute. Child classes are utilized through polymorphic support. Thus, we have a natural transition into this popular usage of object-oriented solutions.
A Lowest Common Denominator
We have discussed the idea of building on methods where possible. When we do, we are creating a lowest common denominator approach to functionality. This is what makes a system logical in its design. Whenever a user (developer) uses a method or attribute there are certain things they can expect that are included. For example, when I have “save” methods in classes, the user expects the class supports persistence. They also will expect a corresponding “load” is going to be available in that class. It is reasonable for the user to expect that a “save” followed by a “load” will result in the before/after instances being identical.
Extending Through Inheritance
We have the aforementioned set of expectations as developers. Those lead us to look at a hierarchy as something that grows as it goes. That means we should extend functionality as we inherit. We should avoid rewriting what the parent does. While we can change or even block behavior in child classes, that is rarely a good design. It is highly frustrating for a developer to have a method available to the parent that is no longer relative (rewritten or unavailable) further down the chain. Think of each step in the hierarchy as a way to build on the parent features. The base class supplies a foundation. The child classes add to that foundation without impacting what has been built in the prior layers. This approach will help your hierarchy help the developers that use it.
