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

[kraemerdr]

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]

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

[mahboubagharbi]

LSP:semantische Integrität und Konsistenz 😉

[kraemerdr]

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]

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]

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]

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]

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]

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]

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]

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).

[mistertakai]

Since y'all are talking about qualities, imho the ISO 25010:2023 qualities indirectly influenced by Liskov's principle would be faultlessness, modularity and testability.

[gernotstarke]

As these were not requested to be added by anyone from the FLWG members, I decide to close the issue. Seems the current formulation is good enough for most.