4

Does Liskov substitution principle apply to inheritance hierarchies where the parent is an abstract class the same way if the parent is a concrete class?

The Wikipedia page list several conditions that have to be met before a hierarchy is deemed to be correct. However, I have read in a blog post that one way to make things easier to conform to LSP is to use abstract parent instead of a concrete class.

How does the choice of the parent type (abstract vs concrete) impacts the LSP? Is it better to have an abstract base class whenever possible?

  • 1
    There is no difference. The important thing is that you respect the supertype's contract. The same rules apply regardless of whether you're implementing an interface or extending an abstract or concrete class. – Doval Jun 6 '14 at 16:27
  • 1
    Can you link to the blog post, so we can see that claim in context? – pdr Jun 6 '14 at 16:42
  • @Doval I understand that, but my question is more like will using an interface or abstract class make it likely that I violate LSP? or will it make no difference at all? – Songo Jun 6 '14 at 16:44
  • 1
    @pdr I lost the link, but I'll try to search for it again. – Songo Jun 6 '14 at 16:46
4

You can answer questions like this by going back to first principles and asking "what is the Liskov substitution principle intended to accomplish?" And the answer to that is that code that works correctly with the superclass should also work correctly with all subclasses. (For CS theory purposes there is a more specific mathematical definition but for the workaday programmer that's likely to only be concern if you are creating a programming language).

So, why would an abstract class be easier? There really is no situation where using a concrete class means you can't possibly follow the Liskov substitution principle in your subclasses. After all, the superclass defines a contract for the subclasses either way. The fact that it also contains one possible implementation of the contract is neither here nor there.

However, one might make the argument that psychologically it's easier to focus on a contract when making an abstract class, and perhaps a concrete class might take an implementation detail and accidentally make that part of the contract. It seems sort of plausible without being really convincing.

As far as never using a concrete class - perhaps a good rule of thumb is to be a bit skeptical of any design philosophy that says you should never use a standard, not totally broken feature of a language. In this case, the chance that you might, maybe, be more likely to make a mistake designing the contract of a concrete class vs. an abstract one - well that would be at best a minor factor in making that decision.

  • Thanks for the answer. About ur point "code that works correctly with the superclass should also work correctly with all subclasses", since we can't instantiate an abstract class doesn't that make it impossible to substitute with a child? – Songo Jun 6 '14 at 16:50
  • 1
    @Songo: the focus is on "works correctly with all subclasses". So its not primarily about substitutibility of the superclass with a subclass, its about substitutibility of one subclass with another subclass. – Doc Brown Jun 6 '14 at 17:00
  • 2
    @Songo: Liskov means that that what works on the superclass should work on subclasses, not that things that don't work on the superclass have to also fail on subclasses. Subclasses implement additional features all the time, that's one of the main reasons we bother to write them. – mjfgates Jun 6 '14 at 17:36
  • 1
    @mfjgates: I think you have the correct thing in mind, but how you describe it, it can be too easily misunderstood. If you add the wrong "additional feature", LSP can be violated either. For example, adding some error checking (which might cause an exception) to a method which was by contract exception-free can make code using those objects unintentionally not working. – Doc Brown Jun 7 '14 at 6:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.