Who is Your Parent for Inheritance:
A Class or an Interface?
One of the Three Pillars of Object Oriented Programming is “Inheritance“. The companion Pillar “Polymorphism” is the second of the three. The third is the most important pillar of them all: “Encapsulation” or Data Hiding.
Conventional use of Inheritance and Polymorphism is Class based. This assumes that the relationship between the Parent Class, Your Daddy, and the Children Classes has an “Is A” relationship.
In the Animal Kingdom an “Is A” relationship is implicit ….
… Unfortunately in Programming Kingdom it is Not
In reality most programming inheritance structure are really a “Behaves Like” relationship more that an “Is A” relationship.
An improper inheritance model leads to unmanageable code over the lifecycle of the code base due to inevitable change requests and feature/functionality additions.
An inheritance model that creates a hierarchy that consumes State DTOs and Behavior Class Objects violates the Modern Developer State Versus Behavior Design Principle (BVSP).
By mixing state objects and behavior objects in the inheritance model you also violate the Liskov Substitution Principle (LSP) as the implementation Base Classes cannot be substituted for their children and still function.
A State Class Is Not a Behavior Class and substitutable in the Class Inheritance Model as required to Comply with the Liskov Substitution Principle
Let’s see how this works in a real Coding Situation:
The Modern Developer’s Error Handling Design Pattern.
The following two tabs change content below.
I am a Principal Architect at Liquid Hub in the Philadelphia area specializing in Agile Practices as a Certified Scrum Master (CSM). I use Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) with Behavior Driven Development (BDD) as my bridge to Agile User Stories Acceptance Criteria in a Domain Driven Design (DDD) implementing true RESTful services