r...@zedat.fu-berlin.de (Stefan Ram) writes: > Julieta Shem <js...@yaxenu.org> writes: >> I'll definitely look up the Liskov >>substitution principle and try to understand it. > > I found the LSP to be very confusing: > > First, it's was hard for me to actually get a clear source > (citation) for it. What exactly are the words of Barbara > Liskov that are called "LSP"? > > Then, I found some words that that might possibly be the LSP > in the words of Barbara Liskov: > > |If for each object o1 of type S there is an object o2 of > |type T such that for all programs P defined in terms of T, > |the behavior of P is unchanged when o1 is substituted for o2 > |then S is a subtype of T. > > This uses nested quantifiers, somewhat like > > ( ∀(o1∈S) ∃(o2∈T) ∀(P∈P(T)) B(P(o2))=(P(o1)) )==> S < T > > . And such a proposition is hard for me to understand!
For me too. > Later, I looked at a book in a bookstore; it was a book > about programming by Barbara Liskov that came out after the > LSP was already mentioned often, and as far as I could see, > that book did not mention the LSP at all, although it > actually had a chapter about subtypes! Do you remember the book's title? > So, here's my personal principle, that I use instead of the LSP: > > An object-oriented program is not complete without proper > documentation, i.e., contracts. The documentation of a class > must be true for all objects of this class and for all objects > of all direct and indirect subclasses. That's much easier to ``parse'' indeed. Thanks for the contribution. (<joke>The empty documentation seems to satisfy the principle.</joke>) > . If this was too long, one could abbreviate this to just: > > Class contracts must hold for subclasses. > > . I think the original LSP unfortunately tried to avoid > references to contracts and just talks about code. -- https://mail.python.org/mailman/listinfo/python-list
