Knowledge

Talk:Liskov substitution principle

Source đź“ť

615:, 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. -- 1192:
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!
179: 102: 81: 50: 1169:"(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". 21: 1086:
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
779:
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
560:
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
1191:
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
623:
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
937:
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
1168:
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
666:
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
453:
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
1087:
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.
801:
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
1202:
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.
200: 631:
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.,
1033:
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.
993:
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.
680:
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.
650:
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...
1000:
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.
526:, 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. 989:
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.
1198:
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.
884:
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
587:
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
711:
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' :
713:
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?
763:
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.
31: 224: 364: 970:
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.
1055:
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?
494:, 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: 1195:
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!
281: 219: 1242: 1082:
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.
152: 142: 1247: 1237: 544:, 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. 118: 486:
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
1218: 326: 300: 165: 109: 86: 522:
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:
389: 1018: 954: 470: 1088: 899: 863: 849: 780:
learning and exploring of people at many levels of understanding. Here I am thinking like a teacher. -- - Sat Nov 8 10:02:35 EST 2008
434: 272: 971: 787: 694:
I don't understand the comparability thing. Clearly if predicate A is weaker than or equal to B, they are necessarily comparable. --
253: 624:
strong, yes. But isn't saying "mandating transparent swapping" just a more practical approach to the previous paragraph, i.e. this:
345: 1214: 1164:
of T without altering the desirable properties of T. Desirable properties can for instance be correctness and task performed.
997:
In effect, you have now contracted not to subclass Circles nor Squares; which is why you have trouble later on when you try.
1137:
with any object of a subtype S) without altering any of the desirable properties of T (correctness, task performed, etc.).
1075: 922: 310: 191: 61: 561:
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.
1149: 1114: 320: 234: 355: 117:
related articles on Knowledge. If you would like to participate, please visit the project page, where you can join
1210: 382: 27: 918:
This point is unclear to me. It appears that Robert Martin did, but we need a citation for something like that.
1014: 466: 950: 826:
Since last July, actually since never, there has been no discussion on the subject of mergeto|Subsitutability.
49: 1092: 1041: 903: 867: 853: 438: 919: 427:
04. Jan. 2011: The external link: The Liskov Substitution Principle, T. S. Norvell, 2003 is not available.
975: 878: 791: 1010: 508:
I found a keynote speech with the same title from 1987 and changed the article intro to point to that. --
1060: 1037: 890: 737: 682: 593: 566: 291: 67: 1206: 1006: 942: 895: 783: 474: 458: 430: 541: 523: 20: 1056: 946: 802:
substitute for the base class. It's bad practice -- but it's bad practice because it violates LSP.
714: 671: 562: 462: 938:
property is truly undecidable, or if additional time/memory would succeed in finding the proof.
807: 670:, also repeated else where) since there were no articles with both bits of information together. 612: 589: 549: 531: 499: 1177: 886: 210: 599:
postconditions for methods in the subclass should be more strict than those in the superclass
1153: 1118: 841: 768: 733: 602:
preconditions for methods in the subclass should be less strict than those in the superclass
262: 114: 1222: 1181: 1096: 1064: 1045: 1022: 979: 958: 927: 907: 871: 857: 811: 795: 772: 756: 741: 732:
This page should be merged with . I've only seen it discussed with regards to inheritance.
717: 698: 685: 674: 570: 553: 535: 517: 502: 442: 752: 513: 336: 178: 833:
mergeto| tag. It's patently ridiculous to have two mergeto proposals at the same time.
201:
Requested articles/Applied arts and sciences/Computer science, computing, and Internet
1231: 803: 545: 527: 1173: 748: 695: 668: 652: 640: 616: 509: 764: 487: 495: 243: 101: 80: 1157: 1126: 667:
classes and the open/closed principle (slightly modified from foldoc.org
540:
Actually, rather than the 1979 CLU reference manual, Wing's PhD thesis (
1161: 1122: 454:
should probably not be inserted without a proper comment, if ever.
747:
Disagree. This is a subtyping issue, not an inheritance issue. --
822:
I removed the mergeto|Substitutability for the following reasons:
542:
http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-299.pdf
524:
http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-225.pdf
639:
Feel free to put in perspective and change whatever you want:)--
985:
The "post conditions" listed for the rectangle object are wrong
319:
Find pictures for the biographies of computer scientists (see
43: 15: 840:|Substitutability is what I'm actually going to argue for -- 1106:
I suggest changing the first sentence of the introduction
1133:
with objects of type S (i.e., an object of type T may be
862:
It's worse than I thought. REDIRECT is more like it. --
605:
no new exceptions should be introduced in the subclass
914:
Who coined it as "The Liskov substitution principle"?
113:, a collaborative effort to improve the coverage of 225:Computer science articles needing expert attention 818:Merge FROM Subsitutability, not merge TO there 365:WikiProject Computer science/Unreferenced BLPs 933:Undecidable Does Not Mean Impossible to Prove 8: 1160:T may be substituted with an object of any 496:http://citeseer.ist.psu.edu/context/93923/0 282:Computer science articles without infoboxes 220:Computer science articles needing attention 47: 1204: 1004: 492:Advanced C++ Programming Styles and Idioms 186:Here are some tasks awaiting attention: 160: 75: 579:Questionable Design by Contract inference 1243:Mid-importance Computer science articles 77: 127:Knowledge:WikiProject Computer science 1248:WikiProject Computer science articles 1238:Start-Class Computer science articles 583:The article currently includes this: 130:Template:WikiProject Computer science 7: 1102:First sentence rephrasing suggestion 482:Incorrect citation of original paper 107:This article is within the scope of 1187:LSP, substitutability are misnomers 66:It is of interest to the following 301:Timeline of computing 2020–present 14: 327:Computing articles needing images 177: 100: 79: 48: 19: 147:This article has been rated as 30:on 22 June 2020. The result of 26:This article was nominated for 1: 1097:21:13, 9 September 2015 (UTC) 980:16:52, 20 February 2013 (UTC) 959:05:41, 21 November 2012 (UTC) 908:17:08, 24 February 2009 (UTC) 812:07:08, 20 February 2009 (UTC) 554:07:03, 20 February 2009 (UTC) 536:06:45, 20 February 2009 (UTC) 475:21:35, 28 November 2009 (UTC) 381:Tag all relevant articles in 121:and see a list of open tasks. 1182:15:42, 3 December 2016 (UTC) 1023:23:44, 2 December 2016 (UTC) 796:15:10, 8 November 2008 (UTC) 773:17:16, 15 October 2008 (UTC) 390:WikiProject Computer science 166:WikiProject Computer science 110:WikiProject Computer science 1150:object-oriented programming 1115:object-oriented programming 1051:Is The Article Even Correct 928:08:24, 26 August 2009 (UTC) 757:00:40, 14 August 2008 (UTC) 742:13:10, 13 August 2008 (UTC) 503:08:15, 29 August 2006 (UTC) 443:01:25, 4 January 2012 (UTC) 321:List of computer scientists 1264: 1223:21:21, 30 April 2020 (UTC) 1046:20:09, 11 March 2013 (UTC) 872:19:35, 22 March 2009 (UTC) 858:19:28, 22 March 2009 (UTC) 619:18:24, May 31, 2005 (UTC) 592:, especially regarding to 518:15:29, 23 March 2008 (UTC) 153:project's importance scale 1065:00:30, 6 March 2014 (UTC) 718:14:18, 15 June 2006 (UTC) 655:14:12, Jun 14, 2005 (UTC) 643:12:46, Jun 14, 2005 (UTC) 571:00:20, 6 March 2014 (UTC) 383:Category:Computer science 159: 146: 133:Computer science articles 95: 74: 1070:Covariance in exceptions 699:12:54, 4 June 2006 (UTC) 686:06:15, 4 June 2006 (UTC) 675:11:57, 3 June 2006 (UTC) 385:and sub-categories with 1152:that states that, in a 1117:that states that, in a 1078:section, the statement 448: 1166: 1139: 1125:of T, then objects of 879:Property_(programming) 662:comparison by strength 346:Computer science stubs 56:This article is rated 1143: 1108: 966:What post conditions? 891:Property_(philosophy) 1211:Bart Jacobs (Leuven) 877:Missleading link to 164:Things you can help 1156:, an object of any 1029:Two way inheritance 889:, or maybe even to 1148:is a principle in 1141:to the more clean 1113:is a principle in 613:Design by Contract 611:As much as I like 590:design by contract 62:content assessment 1225: 1209:comment added by 1025: 1009:comment added by 962: 945:comment added by 925: 898:comment added by 887:Predicate_(logic) 786:comment added by 478: 461:comment added by 433:comment added by 420: 419: 416: 415: 412: 411: 408: 407: 404: 403: 42: 41: 1255: 1154:computer program 1146:Substitutability 1119:computer program 1111:Substitutability 961: 939: 923: 910: 798: 477: 455: 445: 394: 388: 263:Computer science 192:Article requests 181: 174: 173: 161: 135: 134: 131: 128: 125: 124:Computer science 115:Computer science 104: 97: 96: 91: 87:Computer science 83: 76: 59: 53: 52: 44: 23: 16: 1263: 1262: 1258: 1257: 1256: 1254: 1253: 1252: 1228: 1227: 1189: 1104: 1072: 1053: 1031: 987: 968: 940: 935: 916: 893: 882: 820: 781: 730: 664: 581: 484: 456: 451: 428: 425: 400: 397: 392: 386: 374:Project-related 369: 350: 331: 305: 286: 267: 248: 229: 205: 132: 129: 126: 123: 122: 89: 60:on Knowledge's 57: 12: 11: 5: 1261: 1259: 1251: 1250: 1245: 1240: 1230: 1229: 1188: 1185: 1103: 1100: 1084: 1083: 1071: 1068: 1052: 1049: 1030: 1027: 1011:206.191.119.10 986: 983: 967: 964: 947:Caseydoubleyew 934: 931: 915: 912: 881: 875: 846: 845: 834: 827: 819: 816: 815: 814: 799: 776: 775: 760: 759: 729: 726: 725: 724: 723: 722: 721: 720: 704: 703: 702: 701: 689: 688: 663: 660: 659: 658: 657: 656: 645: 644: 636: 635: 634: 633: 626: 625: 609: 608: 607: 606: 603: 600: 580: 577: 576: 575: 574: 573: 558: 557: 556: 483: 480: 463:Vlad Patryshev 450: 449:Why 'mutable'? 447: 424: 421: 418: 417: 414: 413: 410: 409: 406: 405: 402: 401: 399: 398: 396: 395: 378: 370: 368: 367: 361: 351: 349: 348: 342: 332: 330: 329: 324: 316: 306: 304: 303: 297: 287: 285: 284: 278: 268: 266: 265: 259: 249: 247: 246: 240: 230: 228: 227: 222: 216: 206: 204: 203: 197: 185: 183: 182: 170: 169: 157: 156: 149:Mid-importance 145: 139: 138: 136: 119:the discussion 105: 93: 92: 90:Mid‑importance 84: 72: 71: 65: 54: 40: 39: 32:the discussion 24: 13: 10: 9: 6: 4: 3: 2: 1260: 1249: 1246: 1244: 1241: 1239: 1236: 1235: 1233: 1226: 1224: 1220: 1216: 1212: 1208: 1200: 1196: 1193: 1186: 1184: 1183: 1179: 1175: 1170: 1165: 1163: 1159: 1155: 1151: 1147: 1142: 1138: 1136: 1132: 1128: 1124: 1120: 1116: 1112: 1107: 1101: 1099: 1098: 1094: 1090: 1089:84.215.30.244 1081: 1080: 1079: 1077: 1069: 1067: 1066: 1062: 1058: 1050: 1048: 1047: 1043: 1039: 1038:Dirk van Dijk 1035: 1028: 1026: 1024: 1020: 1016: 1012: 1008: 1002: 998: 995: 991: 984: 982: 981: 977: 973: 965: 963: 960: 956: 952: 948: 944: 932: 930: 929: 926: 921: 913: 911: 909: 905: 901: 900:141.14.131.92 897: 892: 888: 880: 876: 874: 873: 869: 865: 864:76.247.105.43 860: 859: 855: 851: 850:76.247.105.43 843: 839: 835: 832: 828: 825: 824: 823: 817: 813: 809: 805: 800: 797: 793: 789: 785: 778: 777: 774: 770: 766: 762: 761: 758: 754: 750: 746: 745: 744: 743: 739: 735: 727: 719: 716: 710: 709: 708: 707: 706: 705: 700: 697: 693: 692: 691: 690: 687: 684: 683:202.7.166.163 679: 678: 677: 676: 673: 669: 661: 654: 649: 648: 647: 646: 642: 638: 637: 632:correctness). 630: 629: 628: 627: 622: 621: 620: 618: 614: 604: 601: 598: 597: 595: 594:specification 591: 586: 585: 584: 578: 572: 568: 564: 559: 555: 551: 547: 543: 539: 538: 537: 533: 529: 525: 521: 520: 519: 515: 511: 507: 506: 505: 504: 501: 497: 493: 489: 481: 479: 476: 472: 468: 464: 460: 446: 444: 440: 436: 435:78.48.103.254 432: 422: 391: 384: 380: 379: 377: 375: 371: 366: 363: 362: 360: 358: 357: 352: 347: 344: 343: 341: 339: 338: 333: 328: 325: 322: 318: 317: 315: 313: 312: 307: 302: 299: 298: 296: 294: 293: 288: 283: 280: 279: 277: 275: 274: 269: 264: 261: 260: 258: 256: 255: 250: 245: 242: 241: 239: 237: 236: 231: 226: 223: 221: 218: 217: 215: 213: 212: 207: 202: 199: 198: 196: 194: 193: 188: 187: 184: 180: 176: 175: 172: 171: 167: 163: 162: 158: 154: 150: 144: 141: 140: 137: 120: 116: 112: 111: 106: 103: 99: 98: 94: 88: 85: 82: 78: 73: 69: 63: 55: 51: 46: 45: 37: 33: 29: 25: 22: 18: 17: 1205:— Preceding 1201: 1197: 1194: 1190: 1171: 1167: 1145: 1144: 1140: 1134: 1130: 1121:, if S is a 1110: 1109: 1105: 1085: 1073: 1054: 1036: 1032: 1005:— Preceding 1003: 999: 996: 992: 988: 972:159.54.131.7 969: 941:— Preceding 936: 917: 883: 861: 847: 837: 830: 821: 788:66.0.235.201 731: 665: 610: 582: 491: 485: 452: 429:— Preceding 426: 373: 372: 356:Unreferenced 354: 353: 335: 334: 309: 308: 290: 289: 271: 270: 252: 251: 233: 232: 209: 208: 190: 189: 148: 108: 68:WikiProjects 35: 1135:substituted 894:—Preceding 782:—Preceding 734:ThomasOwens 488:Jim Coplien 457:—Preceding 58:Start-class 1232:Categories 842:over there 829:There's a 1129:T may be 1076:Principle 804:Bob Kerns 546:Bob Kerns 528:Bob Kerns 423:Dead link 244:Computing 1219:contribs 1207:unsigned 1131:replaced 1057:ADKolsky 1019:contribs 1007:unsigned 955:contribs 943:unsigned 896:unsigned 784:unsigned 715:Jgorman2 672:Jgorman2 563:ADKolsky 471:contribs 459:unsigned 431:unsigned 292:Maintain 235:Copyedit 28:deletion 1174:Jhertel 1162:subtype 1123:subtype 1074:In the 749:Doradus 696:Doradus 653:Doradus 641:Phlebas 617:Doradus 510:Doradus 273:Infobox 211:Cleanup 151:on the 765:Trumpi 500:Kevlin 254:Expand 64:scale. 836:merge 831:newer 728:Merge 337:Stubs 311:Photo 168:with: 1215:talk 1178:talk 1158:type 1127:type 1093:talk 1061:talk 1042:talk 1015:talk 976:talk 951:talk 924:ping 920:Pcap 904:talk 868:talk 854:talk 838:from 808:talk 792:talk 769:talk 753:talk 738:talk 567:talk 550:talk 532:talk 514:talk 467:talk 439:talk 36:keep 34:was 712:--> 498:-- 490:in 143:Mid 1234:: 1221:) 1217:• 1180:) 1172:-- 1095:) 1063:) 1044:) 1021:) 1017:• 978:) 957:) 953:• 906:) 870:) 856:) 848:-- 810:) 794:) 771:) 755:) 740:) 651:-- 596:: 569:) 552:) 534:) 516:) 473:) 469:• 441:) 393:}} 387:{{ 1213:( 1176:( 1091:( 1059:( 1040:( 1013:( 974:( 949:( 902:( 866:( 852:( 844:. 806:( 790:( 767:( 751:( 736:( 565:( 548:( 530:( 512:( 465:( 437:( 376:: 359:: 340:: 323:) 314:: 295:: 276:: 257:: 238:: 214:: 195:: 155:. 70:: 38:.

Index

Articles for deletion
deletion
the discussion

content assessment
WikiProjects
WikiProject icon
Computer science
WikiProject icon
WikiProject Computer science
Computer science
the discussion
Mid
project's importance scale
WikiProject Computer science

Article requests
Requested articles/Applied arts and sciences/Computer science, computing, and Internet
Cleanup
Computer science articles needing attention
Computer science articles needing expert attention
Copyedit
Computing
Expand
Computer science
Infobox
Computer science articles without infoboxes
Maintain
Timeline of computing 2020–present
Photo

Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.

↑