Talk:Liskov substitution principle

Dead link

04. Jan. 2011: The external link: The Liskov Substitution Principle, T. S. Norvell, 2003 is not available. — Preceding unsigned comment added by 78.48.103.254 (talk) 01:25, 4 January 2012 (UTC)

Why 'mutable'?

On Aug.25, 2009, a word 'mutable' was added to 'The Principle' paragraph. I could not find any place in Liskov works where she insists that this "principle" somehow depends on the objects mutability. Although it may be true that the principle is trivial for immutable objects, the mutability issue should probably not be inserted without a proper comment, if ever. —Preceding unsigned comment added by Vlad Patryshev (talk • contribs) 21:35, 28 November 2009 (UTC)

Incorrect citation of original paper

The article states that LSP was introduced in 1993 by Barbara Liskov and Jeanette Wing. However, the term was already in use by 1993, having been used by Jim Coplien in Advanced C++ Programming Styles and Idioms, the copyright date for which is 1992. The paper normally credited with advancing the principle is Barbara Liskov's "Data Abstraction and Hierarchy", which was published in 1988: http://citeseer.ist.psu.edu/context/93923/0 -- Kevlin 08:15, 29 August 2006 (UTC)

I found a keynote speech with the same title from 1987 and changed the article intro to point to that. --Doradus (talk) 15:29, 23 March 2008 (UTC)

I suspect that wasn't the earliest either. I checked the October 1979 edition of the CLU reference manual, and that is definitely too early: http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-225.pdf, though it brushes up against the topic with mention of the type inclusion rule. I think it likely that if you scan all the LCS TRs and TM's between that point and 1987 by Liskov or her grad students, you'll find an earlier reference. Bob Kerns (talk) 06:45, 20 February 2009 (UTC)

Actually, rather than the 1979 CLU reference manual, Wing's PhD thesis (http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-299.pdf, 1983) is a better early endpoint for a search. The seeds are there, but nothing (in a quick scan, anyway) that captures the idea of substitutability concisely. Bob Kerns (talk) 07:03, 20 February 2009 (UTC)

The incorrect citation is still there, at the end of the first paragraph. The correct succinct quote should be "“What is wanted here is something like the following substitution property: 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 is from the 1988 paper.ADKolsky (talk) 00:20, 6 March 2014 (UTC)

Questionable Design by Contract inference

The article currently includes this:

In general, the principle mandates that at all times objects from a class can be swapped with objects from an inheriting class, without the user noticing any other new behaviour. It has effects on the paradigms of design by contract, especially regarding to specification:

• postconditions for methods in the subclass should be more strict than those in the superclass
• preconditions for methods in the subclass should be less strict than those in the superclass
• no new exceptions should be introduced in the subclass

As much as I like Design by Contract, I don't think it's valid to infer anything about preconditions, postconditions, new exceptions, or "any other new behaviour" based on Liskov and Wing's original forumlation. That may be one interpretation or application of the Principle, but to claim that it is "mandated" by the Principle is an opinion that may not be shared by the bulk of practitioners in the field, and at the very least, should be accompanied by a reference. --Doradus 18:24, May 31, 2005 (UTC)

You are very probably more knowledgeable than me about the topic (I'm following a reduced CS curriculum - one year). I have learned this from a theoretical Dutch 2nd bachelor-level textbook on OO, given by a prof enamoured of Design by Contract. My perspective on it is small. And mandating is a bit strong, yes. But isn't saying "mandating transparent swapping" just a more practical approach to the previous paragraph, i.e. this:

Thus, Liskov and Wing's notion of "subtype" is based on the notion of substitutability; that is, if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program (e.g., correctness).

Feel free to put in perspective and change whatever you want:)--Phlebas 12:46, Jun 14, 2005 (UTC)

Reflecting on it, perhaps the preconditions and postconditions are warranted. It's hard to imagine an interpretation of LSP that allows preconditions to be weakened in subclasses, for example. As for the rest, I'm still pondering that... --Doradus 14:12, Jun 14, 2005 (UTC)

comparison by strength

I just put up some changes - I found a little confusion in the "preconditions are weakened" vs "preconditions cannot strengthen" area: my formal logic background and some confusion in my undergrad students who referenced this article made me change it. I also added a bit about the functions using classes and the open/closed principle (slightly modified from foldoc.org[1], also repeated else where) since there were no articles with both bits of information together. Jgorman2 11:57, 3 June 2006 (UTC)

One of my professors pointed out the concept of comparability was missing, so I tightened up the previous changes further and added a short bit on comparability. This can probably do with expansion if I have missed any cases of comparability. 202.7.166.163 06:15, 4 June 2006 (UTC)

I don't understand the comparability thing. Clearly if predicate A is weaker than or equal to B, they are necessarily comparable. --Doradus 12:54, 4 June 2006 (UTC)

In the normal case we have type T with precondition A and subtype S with precondtion A' same or weaker than A. In the incomparable case take T with conditions A and B and S with A' and B' where A' < A and B' > B. In this case the individual conditions can be compared for strength but not the whole condition. Does this make sense (it may not, it is late at night)? If it does, should it be added do you think? Jgorman2 14:18, 15 June 2006 (UTC)

Merge

This page should be merged with [[Inheritance (computer science)]. I've only seen it discussed with regards to inheritance. ThomasOwens (talk) 13:10, 13 August 2008 (UTC)

Disagree. This is a subtyping issue, not an inheritance issue. --Doradus (talk) 00:40, 14 August 2008 (UTC)

Definitely disagree. Liskov and Inheritance are two separate issues. For example, you can have an inheritance relationship in an OO program while still violating the Liskov Substitution Principle. Trumpi (talk) 17:16, 15 October 2008 (UTC)

Disagree. Liscov substitution principle stands on its own. It is more abstract than its source link, if people want the abstraction, let them click. Removing fancy abstractions to their own articals makes the source-link-articals more readable for introductory readers. Artical design should encourge learning and exploring of people at many levels of understanding. Here I am thinking like a teacher. --[Eric Evers] - Sat Nov 8 10:02:35 EST 2008 —Preceding unsigned comment added by 66.0.235.201 (talk) 15:10, 8 November 2008 (UTC)

DO NOT MERGE! Inheritance is about shared implementation. LSP is about contract and interface. LSP applies even with no inheritance. And as noted above, you can break LSP in a subclass -- for example, by reducing the range of values accepted in a method. This renders the subclass not a valid substitute for the base class. It's bad practice -- but it's bad practice because it violates LSP. Bob Kerns (talk) 07:08, 20 February 2009 (UTC)

Merge FROM Subsitutability, not merge TO there

I removed the mergeto|Substitutability for the following reasons:

• Since last July, actually since never, there has been no discussion on the subject of mergeto|Subsitutability.
• There's a newer mergeto| tag. It's patently ridiculous to have two mergeto proposals at the same time.
• mergefrom|Substitutability is what I'm actually going to argue for -- over there.

--76.247.105.43 (talk) 19:28, 22 March 2009 (UTC)

It's worse than I thought. REDIRECT is more like it. --76.247.105.43 (talk) 19:35, 22 March 2009 (UTC)

Missleading link to Property_(programming)

Even though this is an article about programming, the word property in the LSP doesn't refer to the concept of computed object attributes. The link is missleading to the reader, it should either be removed or changed to Predicate_(logic), or maybe even to Property_(philosophy) —Preceding unsigned comment added by 141.14.131.92 (talk) 17:08, 24 February 2009 (UTC)

Who coined it as "The Liskov substitution principle"?

This point is unclear to me. It appears that Robert Martin did, but we need a citation for something like that. Pcap ping 08:24, 26 August 2009 (UTC)

Undecidable Does Not Mean Impossible to Prove

This is a common misunderstanding. An undecidable property could possibly be proven; a program with one statement -- Halt -- is trivially provable as halting, even though in general halting is undecidable. The problem is, for any particular program, failure to construct a proof might mean the property is truly undecidable, or if additional time/memory would succeed in finding the proof. — Preceding unsigned comment added by Caseydoubleyew (talk • contribs) 05:41, 21 November 2012 (UTC)

What post conditions?

The article mentions "the postconditions" for a rectangle object without identifying or describing what those postconditions would be. This text is currently ambiguous and unclear. 159.54.131.7 (talk) 16:52, 20 February 2013 (UTC)

The "post conditions" listed for the rectangle object are wrong

Neither an ellipse nor a rectangle are mathematically required to have their x and y axis vary independently of each other. In fact, this is the defining property of Circles and Squares as sub-classes of Ellipses and Rectangles.

By insisting that the two values *MUST* be required to vary independently, you have lost an important mathematical property of the object in question! In fact, you've forbidden the very property that lets you define a Circle or Square in the first place.

In effect, you have now contracted not to subclass Circles nor Squares; which is why you have trouble later on when you try.

This is why removing the post condition eliminates the problem; contrary to the article's claims, however, removing such a false-promise was doesn't "weaken" the contract; it merely makes it possible to write a mathematically correct one.

— Preceding unsigned comment added by 206.191.119.10 (talk • contribs) 23:44, 2 December 2016 (UTC)

Two way inheritance

Object inherited from can be seen and/or used in two ways: 1) bottom-up: as parent class (top) or 2) top-down: primitive library one want to use and extend from. In second case "Liskov substitution principle" does not apply and contract inheritance is nuisance.

Dirk van Dijk (talk) 20:09, 11 March 2013 (UTC)

Is The Article Even Correct

It seems to me that the article was written based on the 1994 paper and not based on the 1988 paper. This means that most of the discussion within is not relevant to LSP. Thoughts? ADKolsky (talk) 00:30, 6 March 2014 (UTC)

Covariance in exceptions

In the Principle section, the statement

No new exceptions should be thrown by methods of the subtype, except where those exceptions are themselves subtypes of exceptions thrown by the methods of the supertype.

looks to me suspiciously like a cumbersome way of saying that methods must be covariant in exceptions thrown; this could even be unified with covariance of return value into a generalised "covariance of response" - function types are covariant in the return, in any throws and indeed in any other form of response mechanism a language might invent. Of course, not actually throwing a given type of exception is an acceptable implementation of covariant throwing, just as (accepting but) not requiring some input parameter is an acceptable implementation of contravariance for inputs. -- Eddy. 84.215.30.244 (talk) 21:13, 9 September 2015 (UTC)

First sentence rephrasing suggestion

I suggest changing the first sentence of the introduction

Substitutability is a principle in object-oriented programming that states that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of T (correctness, task performed, etc.).

to the more clean

Substitutability is a principle in object-oriented programming that states that, in a computer program, an object of any type T may be substituted with an object of any subtype of T without altering the desirable properties of T. Desirable properties can for instance be correctness and task performed.

I find the current wording rather messy and therefore hard to read, and I believe it is important that the very first sentence is clear, easy to understand, and to the point. Note that with the new wording, there is no need to name the subtype, so introducing "S" is avoided. Also, the parenthesis "(correctness, task performed, etc.)" is moved to a separate sentence to make the first sentence more clean. Finally, it is my belief that everybody understands that "substitute" means "replace", and as "substitute" is the word normally used in computer science, and in the name of the article, I suggest simply using that. If not, " (replaced)" could be added after "substituted".

--Jhertel (talk) 15:42, 3 December 2016 (UTC)

LSP, substitutability are misnomers

I believe we should all do our best to erase all traces of the terms "Liskov Substitution Principle" and "substitutability" from the Internet, starting with this article. Behavioral subtyping is a very meaningful and important concept, and the name "behavioral subtyping" is a great name for it, but LSP and substitutability are terrible names for it. Nothing is being substituted for anything! The principle is about a single object being of two different behavioral types (one of which is a behavioral subtype of the other), not about two different objects! If the supertype is an abstract class, there cannot even *be* any objects whose class is that class, even though behavioral subtyping is perfectly applicable to such cases!

I think Liskov herself feels the same way. If she used substitution-like terms in preliminary work, as far as I know she did *not* use any such terms in the published literature!

If it's okay with people, I'll start by editing the Behavioral subtyping article to make it not be a redirect to this page. I'll copy over all of the content from this page that does not promote the "substitutability" error.

I think the desired final state is that the terms LSP and substitutability are mentioned in a subsection somewhere towards the bottom of the Behavioral subtyping article for historical and debunking reasons, and that the LSP article is turned into a redirect to Behavioral subtyping. — Preceding unsigned comment added by Bart Jacobs (Leuven) (talk • contribs) 21:21, 30 April 2020 (UTC)