title: How can I avoid breaking Liskov Substitution Principle (LSP)?
body: <p>I am in a situation very similar to what <a href="http://www.cc2e.com/Default.aspx" rel="noreferrer">Steve McConnell's</a> in Code Complete has mentioned . Only that my problem is based of Vehicles and Trike happens to be on that by law falls in the category of Cars . Cars had four wheels until now . Any way my domain is unnecessarily complex so it is easy to stick with cats example below.</p>
  
  <blockquote>
    <p>Be suspicious of classes that override a routine and do nothing inside
    the derived routine This typically indicates an error in the design of
    the base class. For instance, suppose you have a class Cat and a
    routine Scratch() and suppose that you eventually find out that some
    cats are declawed and can't scratch. You might be tempted to create a
    class derived from Cat named ScratchlessCat and override the Scratch()
    routine to do nothing. This approach presents several problems:</p>
    
    <p>It violates the abstraction (interface contract) presented in the Cat
    class by changing the semantics of its interface.</p>
    
    <p>This approach quickly gets out of control when you extend it to other
    derived classes. What happens when you find a cat without a tail? Or a
    cat that doesn't catch mice? Or a cat that doesn't drink milk?
    Eventually you'll end up with derived classes like
    ScratchlessTaillessMicelessMilklessCat.</p>
    
    <p>Over time, this approach gives rise to code that's confusing to
    maintain because the interfaces and behavior of the ancestor classes
    imply little or nothing about the behavior of their descendants.</p>
    
    <p>The place to fix this problem is not in the base class, but in the
    original Cat class. Create a Claws class and contain that within the
    Cats class. The root problem was the assumption that all cats scratch,
    so fix that problem at the source, rather than just bandaging it at
    the destination.</p>
  </blockquote>
  
  <p>According to the text from his great book above . Following is bad</p>
  
  <p><strong>Parent Class does not have to be abstract</strong></p>
  
  <pre><code>public abstract class Cat {
     public void scratch() {
        System.out.println("I can scratch");
     }
  }
  </code></pre>
  
  <p><strong>Derived Class</strong></p>
  
  <pre><code>public class ScratchlessCat extends Cat {
     @Override
     public void scratch() {
        // do nothing
     }
  }
  </code></pre>
  
  <p>Now he suggests creating another class <code>Claws</code>, but I do not understand how can I use this class to avoid the need for <code>ScratchlessCat#Scratch</code>.</p>