isaqb-org / curriculum-foundation

iSAQB Curriculum for the CPSA - Foundation Level. This repository contains copyrighted work.
https://public.isaqb.org/
Other
62 stars 14 forks source link

LG 03-04: add additional reason/goal for LSP #600

Open kraemerdr opened 3 weeks ago

kraemerdr commented 3 weeks ago

Aus meiner Sicht ist das primäre Ziel hinter dem LSP weniger "Konsistenz und konzeptionelle Integrität", sondern eher Robustheit (daher auch Teil von SOLID). Wenn sich konkrete Bausteine an die Schnittstellenverträge ihrer Abstraktionen halten, ist weniger unerwartetes (und damit in aller Regel fehlerverursachendes) Verhalten zu erwarten.

Den Aspekt der Robustheit würde ich also zumindest ergänzen: "Liskov’sches Substitutionsprinzip [Liskov 1994] als eine Möglichkeit, Konsistenz, konzeptionelle Integrität und Robustheit zu erreichen (R3)."

gernotstarke commented 3 weeks ago

That's a good argument - although I still see LSP as a purely OO topic.

mahboubagharbi commented 3 weeks ago

LSP:semantische Integrität und Konsistenz 😉

kraemerdr commented 3 weeks ago

That's a good argument - although I still see LSP as a purely OO topic.

Although I have to admit being a huge fan of LSP, I fully agree and would even be fine with removing it from an architecture (!) training altogether. However, if we decide to keep it, linking it to robustness at least provides a justification for its selection.

alxlo commented 3 weeks ago

I'm fine with keeping it as R3, although it will not get a (full) slide in my slide deck as exposing the audience to "Let ⁠ ϕ ( x ) be a property provable about objects ⁠ x of type T. Then ⁠ ϕ ( y ) should be true for objects ⁠ y of type S where S is a subtype of T." leads to a VERY hard and immediate shut down of at least 50% of the participants in my class room. Especially if they don't have an OOP background.

although I still see LSP as a purely OO topic.

au contraire ;-)

Elaborating on behavioral subtyping and that you do not want to care about possible "VIP behaviour" of your specializations/implementations is something that (almost) everyone can relate to and that works fine without OOP and also on multiple levels of architectural design and IMHO conceptually relates strongly to backward compatibility.

mikesperber commented 3 weeks ago

The original paper is about type safety, so it is up to us to speculate on the architectural implications of this.

SOLID's take on LSP is that it's about consistency:

https://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Relevance.html

I'm unsure what "robustness" means in this context, so I'm mildly opposed to adding it.

kraemerdr commented 3 weeks ago

In this case robustness corresponds to the absence of unexpected (and therefore potentially erroneous) behavior that results from components violating the interface contracts given by their abstractions. Example: read-only implementations of the List interface in Java that cause UnsupportedOperationExceptions in arbitrary parts of the code.

mikesperber commented 2 weeks ago

In this case robustness corresponds to the absence of unexpected (and therefore potentially erroneous) behavior that results from components violating the interface contracts given by their abstractions. Example: read-only implementations of the List interface in Java that cause UnsupportedOperationExceptions in arbitrary parts of the code.

Then "robustness" is not the right word. (Cf. https://en.wikipedia.org/wiki/Robustness), which is about reaction to change. The correct term would be "type safety" or "type soundness".

kraemerdr commented 2 weeks ago

From my perspective robustness is not necessarily limited to change, but rather describes the ability to continue operations under difficult circumstances (as described in the German version of the Wikipedia article you referenced):

In der Informatik und Softwareentwicklung bedeutet der Begriff „Robustheit“ die Eigenschaft eines Verfahrens, auch unter ungünstigen Bedingungen noch zuverlässig zu funktionieren.

Avoiding unexpected behavior due to conformity to specified interfaces supports this goal. Type safety on the other hand is more a means than a goal IMHO.

mikesperber commented 1 week ago

From my perspective robustness is not necessarily limited to change, but rather describes the ability to continue operations under difficult circumstances (as described in the German version of the Wikipedia article you referenced):

OK - but what are the "difficult circumstances" in this context?

gernotstarke commented 1 week ago

We are discussing an R3-topic here, just to put the length of the discussion in some context.

I conclude by proposing the following compromise:

DE: "Liskov’sches Substitutionsprinzip als eine Möglichkeit, Konsistenz, konzeptionelle Integrität und Robustheit (im Sinne von Typsicherheit) zu erreichen (R3)."

EN: “Liskov's Substitution Principle as a way to achieve consistency, conceptual integrity and robustness (in the sense of type safety) (R3).