3 ms·

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,

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.
  - humanrebar 10y ago
    > ...C++, where inheritance and polymorphism are welded to one another Technically there many ways to have polymorphism in C++ without inheritance and virtual methods (closures, templates, tagged unions, etc.). In practice, students learn about polymorphism from OOP textbooks and conflate polymorphism and inheritance. The work on 'concepts' for (maybe) C++20 fits more nicely with subtyping and LSP, it sounds like.

3 ms·

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,

by talideon 10y ago

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.
  - humanrebar 10y ago
    > ...C++, where inheritance and polymorphism are welded to one another Technically there many ways to have polymorphism in C++ without inheritance and virtual methods (closures, templates, tagged unions, etc.). In practice, students learn about polymorphism from OOP textbooks and conflate polymorphism and inheritance. The work on 'concepts' for (maybe) C++20 fits more nicely with subtyping and LSP, it sounds like.