LG 03-07: remove Liskov-Substition-Principle from this LG

[gernotstarke]

In my opinion, Liskov has nothing to do with the (general) design of interfaces.

Suggestion is to remove it from THIS learning goal
AND to remove the literature reference.

[mikesperber]

LSP is about specifications, and interfaces are (partial) specifications, so I respectfully disagree.

Quoting Liskov's paper:

This paper defines a new notion of the subtype relation based on the semantic properties of the subtype and supertype. An object’s type determines both a set of legal values and an interface with its environment (through calls on its methods).

[gernotstarke]

but the learning goal relates to interfaces as in API… as far as I interpret it…

…

Am 11.09.2024 um 13:27 schrieb Mike Sperber ***@***.***>: LSP is about specifications, and interfaces are (partial) specifications, so I respectfully disagree. Quoting Liskov's paper: This paper defines a new notion of the subtype relation based on the semantic properties of the subtype and supertype. An object’s type determines both a set of legal values and an interface with its environment (through calls on its methods). — Reply to this email directly, view it on GitHub <#509 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJNIRQG2H3IAIORVNSECKDZWASLVAVCNFSM6AAAAABN7P6BG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBTGM3TCMJRGI>. You are receiving this because you were assigned.

[mikesperber]

but the learning goal relates to interfaces as in API… as far as I interpret it…
…

Sure ... why would that make a difference?

[gernotstarke]

Because the general notion of collaboration between components has nothing to do with subtyping and supertypes.
Liskov is concerned with very specific stuff from (old-school) OO, where (implementation-)inheritance was a major topic.
(which in my observation it is no longer... as interface-inheritance and delegation took over. That is why I consider Liskov to be overly specific in that topic.

In case we want more content on interfaces, I suggest the book from Olaf Zimmermann et al: Patterns of API design, Addison-Wesley 2023.

[mikesperber]

We seem to be reading two different paper:
The LSP is about behavior and its specification in a very general sense, definitely still relevant.
(The word "inheritance" does not even appear in the body of the paper.)

[gernotstarke]

Then we definitely need to reference THAT paper...

[alxlo]

By what means does it help us in the FL training to be super-correct about the scientific origin while many students we have to pick up from the point that they associate this idea with OO programming.
Yes, LSP works very well without talking about inheritance. From my understanding it's about using Abstractions and Specializations in a way that doesn't create undesirable side-effects. Inheritance is just one way to model abstractions and specializations. It works with interfaces as well and has a lot to do with reducing leakyness in abstractions.
And yes, when your abstraction is to leaky (or violates the LSP) then either your abstraction is incomplete or not fit for the purpose - that is, you have a horrible interface with horrible implementations. . https://beza1e1.tuxen.de/leaky_abstractions.html

Maybe we replace "Liskov’s substitution principle [Liskov 1994] as a way to achieve consistency and conceptual
integrity (R3)." with " Strive for consistency an conceptual integrity by considering the LSP (ref) and by minimizing leakyness (ref)"

[claudineallen]

Hello everyone. I am just joining the conversation and perhaps a bit late. The new version definitely flows better than the previous logically. In particular, am happy to see that the study on quality requirements and constraints is introduced before the section on evaluation and that we now explicitly mention evaluation of the software architecture with specific reference to quality requirements. I suggest we include Liskov substitution under conceptual integrity in LG-03-04. It can then also be referenced in the discussions under LG-03-07 in the manner suggested by alxlo. In both cases this can be (R3). Thanks to all those who have put so much effort into this work.

[rhoadesre]

I'm also of the opinion, that Liskov should be removed here. It seems my understanding is also different than Mike's.

[gernotstarke]

I moved the sentence

** Liskov's substitution principle <> as a way to achieve consistency and conceptual integrity (R3).

to LG-03-04 under conceptual integrity.

[gernotstarke]

PR: #563 has been merged. Closing this issue.