Lazy Inheritance Bugs

I ran across another type of bug yesterday. I'm calling it the Lazy Inheritance Bug. I'm not sure where I first heard the term lazy inheritance, but I've always thought it was a good way to explain the power of delegation, and until yesterday didn't even realize that it could encompass a category of bugs.

Lazy Inheritance

If you've done any object oriented development, you've probably heard the terms is-a and has-a. Is-a is a way to determine if one object should inherit from another. It's not the best criteria to use, but it is a pretty good rule of thumb. Unfortunately, some developers get into the habit of inheriting from another class just to get some reuse. Some method in a class does some work that they need, so they extend that class to get that work for free. That's lazy inheritance.

Lazy Inheritance Bugs

When you use lazy inheritance, you begin a cascading hierarchy that can result in bugs. You extend some class to get some free work. Someone else extends your class to get some of your free work. Someone extends that class to get more free work until you have some methods very far down the hierarchy that depend on methods way up the hierarchy. Now, the author of the original class changes a method and something completely different breaks. That's the Lazy Inheritance Bug.

And that's why terms like is-a exist. To give you some criteria from which to decide if you should inherit from another class. Barbara Liskov provided a better criteria called the Liskov Substitution Principle (LSP). Basically, given a class A that inherits from class B then any class C that has a reference to class A should also work when given a reference to class B without having to know it has a B. In other words, class B should be substitutable for class A. When you use lazy inheritance, you violate the LSP by definition.

Avoiding lazy inheritance bugs is easy: don't use inheritance unless you can conform to the LSP.

Delegation

Before you use inheritance to get reuse or avoid duplication, take some time to consider delegation instead. Here's an example:

Inheritance:

public class Car {
  public void go() {
    // goes pretty fast
  }
}

public class SportsCar extends Car {
  public void go() {
    // goes really fast
  }
}

Notice the only difference between a Car and a SportsCar is the engine. We could use delegation and only have one type of car.

public interface Engine {
  void go();
}

public class EconomyEngine implements Engine {
  public void go() {
    // goes pretty fast
  }
}

public class SportsEngine implements Engine {
  public void go() {
    // goes really fast
  }
}

public class Car {
  private Engine engine;
  
  public Car(Engine engine) {
    this.engine = engine;
  }

  public void go() {
    engine.go();
  }
}

So now you can configure your car with whatever engine you want. This example doesn't seem to hold its weight. There's still inheritance going on, but now it's with Engine and not Car. What gives? Well, just add one more option to see how delegation almost always wins:

public class FamilyCar {
 public void go() {
   // goes pretty fast
 }

 public void turn() {
   // turns OK
 }
}

public class SportsCar {
 public void go() {
   // goes really fast
 }

 public void turn() {
   // turns really well
 }
}

public class SportSuv {
 public void go() {
   // goes really fast
 }

 public void turn() {
   // turns OK
 }
}

public class EconomyCar {
 public void go() {
   // goes pretty fast
 }

 public void turn() {
   // turns really well
 }
}

How can we use inheritance to combine just these two features? With delegation it's easy:

public interface Engine {
 void go();
}

public class SportsEngine implements Engine {
 public void go() {
   // goes really fast
 }
}

public class EconomyEngine implements Engine {
 public void go() {
   // goes pretty fast
 }
}

public interface Suspension {
  void turn();
}

public class SportsSuspension implements Suspension {
  public void turn() {
    // turns really well
  }
}

public class EconomySuspension implements Suspension {
  public void turn() {
    // turns OK
  }
}

public class Car {
  private Engine engine;
  private Suspension suspension;
  public Car(Engine engine, Suspension suspension) {
    this.engine = engine;
    this.suspension = suspension;
  }

  pubic void go() {
    engine.go();
  }

  public void turn() {
    suspension.turn();
  }
}

Now we can configure any Car with any type of Engine and Suspension. When you start thinking about the braking system and traction control and air bags and body style and on and on, you can see that trying to use inheritance for each possible car configuration would get out of hand really fast. Delegation allows you to configure your car with each component and have the reuse in the components and not in the hierarchy. And that's how to squash lazy inheritance bugs before they hatch.