Differences

This shows you the differences between two versions of the page.

--- principles:liskov_substitution_principle [2021-09-02 18:26] – old revision restored (2021-09-02 10:48) 65.21.179.175
+++ principles:liskov_substitution_principle [2021-09-02 18:26] – old revision restored (2021-05-11 22:03) 65.21.179.175
@@ Line 6: / Line 6: @@
 ===== Context =====
 /* fill in contexts here: */
-  * [[contexts:Object-Oriented Design]]
+  * [[contexts:Object-Oriented Design]]
+  * [[contexts:API Design]]
@@ Line 12: / Line 13: @@
 > "Subtypes must be substitutable for their base types."((Robert C. Martin: //Agile Software Development, Principles, Patterns, and Practices//, p. 111))
 ===== Description =====
+Object-oriented programming languages allow to derive subtypes from base types and subtype polymorphism allows to pass an object of a subtype where ever an object of the supertype is specified. Suppose ''P'' and ''Q'' are types (i.e. classes or ''interface''s) and ''Q'' is derived from ''P'' (so ''Q'' is the subtype and ''P'' is the base type or supertype). A method ''m'' requiring a parameter of type ''P'' can be called with objects of type ''Q'' because every object of type ''Q'' is also an object of type ''P''. This is always true as typically object-oriented programming languages are constructed in that way.
-===== Rationale =====
+But the programming language does not enforce that the subtype also behaves like the supertype. Method ''m'' may work with an object of type ''P'' but not with an object of type ''Q''. LSP demands that a subtype (''Q'' in the example) has to be constructed in a way that it behaves like the supertype if it is called through the supertype interface. ''Q'' may have further methods and it may do additional things not observable by ''m'' but ''m'' shall be able to safely assume that its parameter behaves like an object of type ''P'' with respect to all observable state.
+===== Rationale =====
+Let ''P'' and ''Q'' be types and ''Q'' a subtype of ''P''. If LSP is not adhered to, there is an operation accessible through the interface of ''P'' which behaves differently when called on ''Q''. So code which is written in terms of ''P'' will not expect the behavior and will not work as desired.
 ===== Strategies =====
@@ Line 34: / Line 42: @@
 ===== Origin =====
-Barbara Liskov: //[[http://portal.acm.org/citation.cfm?id=62141|Data abstraction and hierarchy]]//
+Barbara Liskov: //[[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.12.819|Data abstraction and hierarchy]]//
 ===== Evidence =====
 /* Comment out what is not applicable and explain the rest: */
-/*
-  * [[wiki:Proposed]]
+/*  * [[wiki:Proposed]]*/
-  * [[wiki:Examined]]
-  * [[wiki:Accepted]]
+  * [[wiki:Examined]] LSP describes an effect created by object-oriented type systems. There is no human factor in there, so experiments are not needed. The effect was described and thoroughly examined by Barbara Liskov and Jeanette Wing(([[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.28.2615]])). Their reasoning is presented in section [[#rationale]] in a simplified form.
-  * [[wiki:Questioned]]
+  * [[wiki:Accepted]] LSP is widely known in practice, mainly because it is part of Robert C. Martin's [[collections:SOLID]] principle collection.
-*/
+/*  * [[wiki:Questioned]]*/
 ===== Relations to Other Principles =====
@@ Line 67: / Line 76: @@
-===== Example =====
+===== Examples =====
@@ Line 83: / Line 92: @@
   * [[wiki>LiskovSubstitutionPrinciple]]
   * [[wp>Liskov Substitution Principle]]
+  * Barbara H. Liskov , Jeanette M. Wing: //[[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.39.1223|A Behavioral Notion of Subtyping]]//
+  * Barbara H. Liskov , Jeanette M. Wing: //[[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.28.2615|Behavioral Subtyping Using Invariants and Constraints]]//