Principles Wiki

User Tools

Site Tools

You are here: Principles Wiki » principles » Liskov Substitution Principle (LSP)
principles:liskov_substitution_principle

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
principles:liskov_substitution_principle [2021-09-02 18:26] – old revision restored (2021-09-02 10:48) 65.21.179.175principles:liskov_substitution_principle [2021-10-18 21:50] (current) – +++ restored +++ christian
Line 1: Line 1:
-====== Liskov Substitution Principle ======+====== Liskov Substitution Principle (LSP) ======
  
 ===== Variants and Alternative Names ===== ===== Variants and Alternative Names =====
Line 6: Line 6:
 ===== Context ===== ===== Context =====
 /* fill in contexts here: */ /* fill in contexts here: */
-  * [[contexts:Object-Oriented Design]] +  * [[contexts:Object-Oriented Design]] 
 +  * [[contexts:API Design]]
  
  
 ===== Principle Statement ===== ===== Principle Statement =====
 +
 +> "Subtypes must be substitutable for their base types."((Robert C. Martin: //Agile Software Development, Principles, Patterns, and Practices//, p. 111))
  
  
 ===== Description ===== ===== Description =====
  
 +Object-oriented programming languages permit the derivation of subtypes from base types, and subtype polymorphism allows the passing of 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 =====+The programming language does not enforce that the subtype 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 ===== ===== Strategies =====
  
   * Only strengthen invariants in subclasses; never weaken them   * Only strengthen invariants in subclasses; never weaken them
-  * Only waken preconditions when overriding methods+  * Only weaken preconditions when overriding methods
   * Only strengthen postconditions when overriding methods   * Only strengthen postconditions when overriding methods
 +  * Use Delegation instead of Inheritance
 +  * Figure out better abstractions
 +
 +===== Caveats =====
 +
 +See section [[#contrary principles]].
 +
 +
 ===== Origin ===== ===== Origin =====
 +
 +Barbara Liskov: //[[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.12.819|Data abstraction and hierarchy]]//
  
  
 ===== Evidence ===== ===== Evidence =====
 /* Comment out what is not applicable and explain the rest: */ /* 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 ===== ===== Relations to Other Principles =====
Line 47: Line 67:
 ==== Complementary Principles ==== ==== Complementary Principles ====
  
-  * [[Information Hiding/Encapsulation]] (IH/E): For the purpose of inheritance there can be a wider ''protected'' interface. This typically weakens encapsulation to some extend. +  * [[Model Principle]] (MP): MP demands inheritance relations to resemble an "is-a" relationship. This means that an object of the subclass is also an object of the superclass. This is always true in a technical sense as this is how object-oriented programming languages handle inheritance hierarchies. However MP demands that is shall be true in the model, too. This is slightly different from LSP which rather is about a "is-substitutable-for" relationship.
-  * [[Invariant Avoidance Principle]] FIXME +
-  * [[Model Principle]] (ML): MP demands inheritance relations to resemble an "is-a" relationship. This means that an object of the subclass is also an object of the superclass. This is always true in a technical sense as this is how object-oriented programming languages handle inheritance hierarchies. However MP demands that is shall be true in the model, too. This is slightly different from LSP which rather is about a "is-substitutable-for" relationship.+
   * [[Principle of Separate Understandability]] (PSU): When building inheritance hierarchies, LSP constrains how subclasses are constructed. Namely they should comply with the superclass contract. PSU on the other hand demands that the superclass shall be separately understandable, which means that knowledge of concrete subclasses and their needs should not be necessary to understand the superclass. So a superclass should not have a specific functionality, etc. just because a particular subclass needs this. In contrast to that the superclass of course may provide ''protected'' features for subclasses in general. But it should be inherently clear that subclasses in general may need this functionality without looking at a particular one.   * [[Principle of Separate Understandability]] (PSU): When building inheritance hierarchies, LSP constrains how subclasses are constructed. Namely they should comply with the superclass contract. PSU on the other hand demands that the superclass shall be separately understandable, which means that knowledge of concrete subclasses and their needs should not be necessary to understand the superclass. So a superclass should not have a specific functionality, etc. just because a particular subclass needs this. In contrast to that the superclass of course may provide ''protected'' features for subclasses in general. But it should be inherently clear that subclasses in general may need this functionality without looking at a particular one.
  
Line 57: Line 75:
 {{page>collections:SOLID#Box}} {{page>collections:SOLID#Box}}
  
-===== Example =====+ 
 +===== Examples =====
  
  
 ===== Description Status ===== ===== Description Status =====
 /* Choose one of the following and comment out the rest: */ /* Choose one of the following and comment out the rest: */
-[[wiki:Stub]] +/*[[wiki:Stub]]*/ 
-/*[[wiki:Incomplete]]*/+[[wiki:Incomplete]]
 /*[[wiki:Complete]]*/ /*[[wiki:Complete]]*/
 +
  
 ===== Further Reading ===== ===== Further Reading =====
  
-  * Robert C. Martin: //Agile Software Development, Principles, Patterns, and Practices//+  * Robert C. Martin: //Agile Software Development, Principles, Patterns, and Practices//, p. 111--125
   * [[http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod|ButUncleBob: Principles of OOD]]   * [[http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod|ButUncleBob: Principles of OOD]]
 +  * [[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]]//
 +
 +===== Discussion =====
 +
 +Discuss this wiki article and the principle on the corresponding [[talk:principles:Liskov Substitution Principle|talk page]].
 +
principles/liskov_substitution_principle.1630599986.txt.gz · Last modified: by 65.21.179.175