#42-The Agile Use of Inheritance

Various technologies provide us with the concept of "inheritance".  What should this used for, ideally, in an agile development environment?  This episode addresses this question in a way that should be interesting to non-technical people as well as developers and testers.

Transcript

The Agile Use of Inheritance

This week I'm going to delve into something a bit more technical, but in a way I think (hope) many will find interesting.  Also, if you are not technical yourself, you likely have colleagues that are, and you should feel free to share this material with them.

The concept of inheritance in systems development can mean many different things depending on what part you play.  For a mid-tier developer, it usually refers to creating a subclass from an existing base class.  For someone creating a webpage, if they use cascading style sheets this is also a form of inheritance because they "cascade" and therefore pages deep in the structure take on the appearance of the site overall.  Database DDLs (data description Languages) can, in some cases, take a base or "vanilla" database structure and then, using that as starting template, allow the DBA to create special aspects for a particular installation.  There are other examples.

But what role do these approaches take in the agile notion of "Software as A Service" (SAAS), which I discussed last week?

My friend and colleague Amir Kolsky once put it this way to me:  If we consider inheritance the way non-technical people think about it, there is wisdom to be gained.  He suggested that there are two forms of inheritance in humans which he called "Life Inheritance" and "Death Inheritance".

Life Inheritance is where children inherit genetic traits from their parents.  Tall parents tend to have tall children, and things like hair color and the shape of the face also tend to be derived from the characteristics of our progenitors.  Children do differ from their parents too, of course, but a lot of your physical details are based on those of your parents.

Death Inheritance is where children take possession of their parent's property and wealth when those parents pass away.  Unless otherwise stipulated, children get their parents' "stuff" when those parents die.

So, life inheritance means that children are like their parents in terms of their attributes at birth, which stay with them throughout life.  Death inheritance means that children receive their accumulated things when the parents reach the end of their lives.

In systemic inheritance we can use the mechanisms that technology provides in similar ways. 

If a component is "inherited" from a base component, then we might do this in order for the fields and functions of that parent/base component to also appear in the child.  Although base component is not "gone", still the child "gets its stuff".  The more child components are created, the more this happens, and if children are also derived from this then this effect will cascade down.

On the other hand, a child component can usually be substituted for a base component without changing the rest of the system.  This creates a pluggability that allows us to flexibly change the operation of a system with minimal maintenance.

The latter use is more agile that the former. 

Using inheritance to "get stuff" also creates coupling.  It's not always wrong to use it this way, but the more you do the more difficult changes can be because changing a parent component will tend to change the children as well, which may not be desirable in all cases.   

Using inheritance to allow for plug-and-play reuse of components makes all our work more valuable going forward and also allows us to more thoroughly embrace change, as agile says we must.

As may not be too surprising to those that have heard me on these topics before, the design patterns tend to use inheritance in the “Life Inheritance” sense.  You can see examples of this by visiting the disciplined agile design pattern repository:

https://www.pmi.org/disciplined-agile/the-design-patterns-repository