Liskov substitution principle (LSP)

SOLID principles:

• Single responsibility principle (SRP)
• Open/closed principle (OCP)
• Interface segregation principle (ISP)
• Dependency inversion principle (DIP)

Use inheritance when you want to alter the behavior implemented by the non-abstract class. Use inheritance when you want to define the behavior not implemented, but specified by the abstract class. Implement interface when your class conforms to that interface. There are no other cases when you should want to do it. In other words, when you use extends/implements the interface/protocol should remain the same.

Let's consider an example:

(not for production, illustrative purposes only)

// there's a standard class ArrayList<t> in Java

public class MyList<T> extends ArrayList<T> {
  public void dumpFancily() {
    System.out.printf("I have %d items and here they are:\n", size());
    for(T item : this) {
      System.out.printf("I have %s\n", item);
    }
  }
}

The only aim of MyList is just to add a convenient method dumpFancily(). This convenience will only remain as long as your references to the objects of this class have a type of MyList. As soon as you use something like Collections.unmodifiableList() against your MyList, you'll lose your dumpFancily(), since unmodifiableList() returns List<T>:

MyList<Integer> myList = new MyList<integer>();
myList.add(123);
myList.dumpFancily(); // OK, you rock

// ERROR, won't compile
MyList<Integer> myReadonlyList = Collections.unmodifiableList(myList); 
// ERROR, won't compile
Collections.unmodifiableList(myList).dumpFancily();

So, what's the big idea of your MyList<T> if you can't work with the standard library?