How can I avoid breaking Liskov Substitution Principle (LSP)?

Question

I am in a situation very similar to what Steve McConnell\'s in Code Complete has mentioned . Only that my problem is based of Vehicles and Trike happens to be on that by law

Answer 1

You would still have a scratch() method, but it will not be overridden by the derived classes:

public class Cat {
  Claw claw_;
  public Cat(Claw claw) {claw = claw_;}
  public final void scratch() {
    if (claw_ != null) {
      claw_.scratch(this);
    }
  }
}

This allows you to delegate the scratching logic to the contained Claw object, if present (and not scratch if there are no claws). Classes derived from cat have no say in the matter on how to scratch, so no need to create shadow hierarchies based on abilities.

Also, because the derived classes cannot change the method implementation, there is no problem of them breaking the intended semantics of the scratch() method in the base class's interface.

If you take this to the extremes, you might find that you have a lot of classes and not many derivations -- most logic is delegated to the composition objects, not entrusted to the derived classes.