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.