The Liskov Substitution Principle

[ZiCog]

Moderator note: This discussion was split from University level Rust courses?

@Inactive

it still felt like Composition over Inheritance had no real theoretical or academic basis. At university, Object Oriented Design principles are taught in a very thorough manner explaining where they came from, what they mean, and how to think in OO, but it feels like that is not there for Rust.

I'm wondering where I find any theoretical basis for Object Oriented Design?

I must admit that I am woefully ignorant of any Software Engineering "theory" since being taught "Structured Programming" back in the late 1970's. Since first having to struggle with C++ since the turn of the century I slowly became aware of some principles of Object-Oriented design. As in: http://www.cs.utsa.edu/~cs3443/notes/designPrinciples/designPrinciples.html. Which seem to be a collection of "rules of thumb" people have developed over decades to save themselves from the mess they can get into in languages like C++, rather than any theoretical basis.

Sadly most code bases I have been thrown into over the years did not adhere to any such principles much. Not in C++ or C#.

[VorfeedCanal]

@ZiCog

I'm wondering where I find any theoretical basis for Object Oriented Design?

TL;DR version: OOP is a warp startship design in a world where warp drive doesn't exist.

It all started with Liskov's paper. 20 years after OOP was invented it, finally, got a theoretical base.

After that there was Object Oriented Analysis and Design With Applications which mentioned that article (and later Design Principles and Design Patterns included it in SOLID which architecture astronauts like to talk about so much).

But only much, much later it become apparent that LSP is just something mere mortals couldn't handle: it's really hard to verify by human and I know of no language which guarantees it via some formal mechanism.

That's when OOP turned into pile of hacks: if we can not prove that some important property that we need is holding up then maybe we can just ensure that it's Ok with tests?

This kinda-sorta-maybe works, but turned the whole thing into bloated monster. What started as a clever hack designed to reduce amount of code written become an opposite.

@ZiCog

Which seem to be a collection of "rules of thumb" people have developed over decades to save themselves from the mess they can get into in languages like C++, rather than any theoretical basis.

They can be formalized. But no one usually does that. Because if you do that then you find out just how crazy complex the code you are creating actually is. All the touted advantages of OOP would be lost.

And all that is because it's hard to ensure LSP properties still work. If you would think about it all the other parts of SOLID are there to ensure LSP still holds.