User Tools

Site Tools


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 revisionBoth sides next 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-09-02 18:26] – old revision restored (2021-09-02 10:48) 65.21.179.175
Line 1: Line 1:
-====== Liskov Substitution Principle ======+====== Liskov Substitution Principle (LSP) ======
  
 ===== Variants and Alternative Names ===== ===== Variants and Alternative Names =====
Line 11: Line 11:
 ===== 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 =====
Line 23: Line 24:
   * Only waken preconditions when overriding methods   * Only waken 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://portal.acm.org/citation.cfm?id=62141|Data abstraction and hierarchy]]//
  
  
Line 47: Line 58:
 ==== 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 56: Line 65:
 {{page>collections:OOD Principle Language#Box}} {{page>collections:OOD Principle Language#Box}}
 {{page>collections:SOLID#Box}} {{page>collections:SOLID#Box}}
 +
  
 ===== Example ===== ===== Example =====
Line 65: Line 75:
 /*[[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]]
 +
principles/liskov_substitution_principle.txt · Last modified: 2021-10-18 21:50 by christian