Techniques for Writing Inheritable Code

Code quality is directly impacts how maintainable inheritance hierarchies and modules are. Following techniques make life easier when writing code which shares inherited behaviour.

Recognise the Antipatterns

There are antipatterns that indicate that our code might need inheritance.

1. An object using a variable with a name like type or category to determine what message to send to self will lead to maintenance nightmares, as every addition of a new type will lead to code change.
   The solution is to refactor the code to implement inheritance by moving the common code in an abstract superclass and creating subclasses for the different types. Any newly added type can just be implemented by creating another concrete subclass.
2. An object checking the class of another other object to determine what message to send means we have missed a duck type and yet again another maintenance nightmare as introduction every new class will call for code change.
   Here, since all the objects whose classes are being checked play a common role, this role should be made into a duck type and receivers should implement the duck type’s interface. Now, the original object can send one single message to every receiver and because each receiver plays the role it will understand the common message. In addition to sharing an interface, These duck types might also share behaviour in which case, move the shared code into a module and include it in each class or object that plays the role.

Push for Abstraction

All the code in a superclass should be applicable to all of its subclasses. Superclasses must not contain code that applies to only some, not all, of its subclasses. The same goes for modules as well.

Faulty abstractions cause inheriting objects to contain incorrect behaviour

Such faulty abstractions lead to bad quality code which forces the programmer to know specifications and dependencies.

Consider a subclass overriding a method to raise a NotImplementedError exception. A subclass overriding a method to declare that they do not do that thing just seems counterintuitive. It pretty much means that subclass is not that thing. If we cannot correctly identify the abstraction there may not be one, and if no common abstraction exists then inheritance is not the solution.

Honour the Contract

Subclasses agree to a contract; they promise to be substitutable for their superclasses.

Substitutability means subclasses must identically respond to every message in the superclass’s interface. They must not do anything that forces others to check their type in order to know what to expect.

In order to do this the Liskov Substitution Principle (LSP) must be followed.

Use the Template Method Pattern

Separate the abstract from the concrete. The abstract code contains the basic logic and the concrete inheritors specialise that logic by overriding these template methods to create variations specific to the corresponding concrete classes.

Create Shallow Hierarchies

Every hierarchy can be imagined as a pyramid that has both depth and breadth.

An object’s depth is the number of superclasses between it and the top. Its breadth is the number of its direct subclasses. A hierarchy’s shape, which is defined by its overall breadth and depth, determines its complexity.

• Shallow, narrow hierarchies are easy to understand.
• Shallow, wide hierarchies are a bit more complicated.
• Deep, narrow hierarchies are a relatively more challenging and have a tendency to get wider because of their depth.
• Deep, wide hierarchies are difficult to understand, costly to maintain, and should be avoided.

Because objects depend on everything above them, a deep hierarchy with a very long search path for message resolution will have a large set of built-in dependencies which yet again forces the programmer to have knowledge about these dependencies in order to make a code change.