I’m a big fan of patterns and principles. And I’m going to explain all SOLID principles in different blog posts. This post is all about LSP.

LSP says that you should always be able to use a base class or interface instead of the actual implementation and still get the expected result. If you can’t, you are breaking LSP.

An example:

public interface IDuck
{
   void Swim();
}
public class Duck : IDuck
{
   public void Swim()
   {
      //do something to swim
   }
}
public class ElectricDuck : IDuck
{
   public void Swim()
   {
      if (!IsTurnedOn)
        return;

      //swim logic
   }
}

And the calling code:

void MakeDuckSwim(IDuck duck)
{
    duck.Swim();
}

As you can see, there are two examples of ducks. One regular duck and one electric duck. The electric duck can only swim if it’s turned on. This breaks the LSP since it must be turned on to be able to swim (the MakeDuckSwim method will not work if a duck is electric and not turned on).

You can of course solve it by doing something like this:

void MakeDuckSwim(IDuck duck)
{
    if (duck is ElectricDuck)
        ((ElectricDuck)duck).TurnOn();
    duck.Swim();
}

But that would break the Open/Closed principle (SOLID) and has to be implemented everywhere (and therefore still generate unstable code).

The proper solution would be to automatically turn on the duck in the Swim method and by doing so make the electric duck behave exactly as defined by the IDuck interface.

The solution with turning on the duck inside the Swim method can have side effects when working with the actual implementation (ElectricDuck). But that can be solved by using an explicit interface implementation. In my opinion, it’s more likely that you get problems by not turning it on in Swim since it’s expected that it will swim when using the IDuck interface.

What LSP is really saying is that all classes must follow the contracts that they have been given. Just as you may not update items in your website with GET if you are following the HTTP protocol.