4 ms·

Liskov Substitution: An object can be replaced by supertype without breaking the program Shouldn't that be subtype? Or am I misremembering this?

• fishnchips 10y ago
  Yup, you remember it correctly.
• ethagnawl 10y ago
  You're correct. From Wikipedia[0]: > Liskov's notion of a behavioral subtype defines a notion of substitutability for mutable objects; that is, if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program (e.g. correctness). 0: https://en.wikipedia.org/wiki/Liskov_substitution_principle https://en.wikipedia.org/wiki/Liskov_substitution_principle
  • Ntrails 10y ago
    Surely it follows logically anyway? Assuming sub/super are referring to inheritance (sorry, I'm a bad), a sub contains all of a super and more. Passing through an object with more shouldn't break anything. But a super might lack things the sub has, thereby breaking assumptions about what will be present. I feel like the principle would be broken by the objects/inheritance being badly used rather than the calling code though?
    • talideon 10y ago
      LSP doesn't specifically deal with inheritance; it's equally applicable to interface implementation.
  • coderjean1 10y ago
    Yes you are totally right. I mistyped a word. Where it says supertype I actually meant subtype. I corrected the article.
• humanrebar 10y ago
  Many developers, myself included, aren't fans of the Liskov Substitution Principle because base classes aren't a great way to reuse code. Prefer composition over inheritance for reuse. And prefer interfaces over base classes (abstract or concrete) for polymorphic behavior. There aren't many situations where Liskov is even relevant with those principles in mind. I have to inherit from a concrete type from time to time when when a third-party API requires it. And, inevitably, my design becomes more convoluted than necessary because of that.
  • talideon 10y ago
    That's a very narrow reading of LSP. If you're dealing purely with interfaces, LSP is still just as useful. In that case, if two types share the same interface, it should be possible to substitute objects of one type for those of the other where that interface is expected and not break the program.
    • humanrebar 10y ago
      In that case, it's better to phrase the guideline in terms of interfaces and implementations to avoid the digressions into ABCs. The interfaces that complicate my designs were written by well-meaning engineers that thought ABCs are best practice if the LSP is followed. That's not the case anymore and I'd rather we start teaching from a more sensible default.
      • talideon 10y ago
        LSP came out of Liskov's work on CLU (amongst other things). CLU didn't have inheritance, though it did have have 'interface specifications'. LSP is most properly thought of as pertaining to interfaces rather than inheritance. LSP as most people seem to currently conceive it is coloured by their experience with languages like C++, where inheritance and polymorphism are welded to one another. Same goes for the likes of Java, albeit to a lesser extent. In the case of languages like that, LSP also needs to deal with the subclass/superclass relationship, and that has over time overshadowed its most important aspect: substitutability of implementations.