User Tools

Site Tools


principles:encapsulate_the_concept_that_varies

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:encapsulate_the_concept_that_varies [2021-09-02 12:26] – old revision restored (2021-05-19 11:22) 65.21.179.175principles:encapsulate_the_concept_that_varies [2021-10-18 21:31] (current) – +++ restored +++ christian
Line 5: Line 5:
 ===== Context ===== ===== Context =====
 /* fill in contexts here: */ /* fill in contexts here: */
-  * [[contexts:Object-Oriented Design]]  +  * [[contexts:Object-Oriented Design]] 
 +  * [[contexts:API Design]] 
 +  * [[contexts:Architecture]]
  
 ===== Principle Statement ===== ===== Principle Statement =====
Line 47: Line 48:
     * Visitor: New operations have to be added to a given more or less static inheritance structure of classes.     * Visitor: New operations have to be added to a given more or less static inheritance structure of classes.
     * ...     * ...
 +
 +===== Caveats =====
 +
 +See section [[#contrary principles]].
 +
  
 ===== Origin ===== ===== Origin =====
 +
 +The principle is stated, explained and used in the GoF book:
  
 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: //[[wp>Design Patterns|Design Patterns: Elements of Reusable Object-Oriented Software]]// ("GoF book"), p. 29 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: //[[wp>Design Patterns|Design Patterns: Elements of Reusable Object-Oriented Software]]// ("GoF book"), p. 29
 +
 +But the idea if ECV is actually much older. It was first presented in
 +
 +David Parnas: //[[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.132.7232|On the Criteria To Be Used in Decomposing Systems into Modules]]//
 +
  
 ===== Evidence ===== ===== Evidence =====
Line 64: Line 77:
  
 ==== Generalizations ==== ==== Generalizations ====
- 
-  * [[Generalization Principle]] (GP): Encapsulating a varying concept typically results in a more generally applicable solution. This is especially true when an abstract concept is encapsulated by introducing an interface or an abstract class. 
  
 ==== Specializations ==== ==== Specializations ====
Line 75: Line 86:
  
   * **[[More Is More Complex]] (MIMC)**: ECV demands adding a new class for a new varying concept.   * **[[More Is More Complex]] (MIMC)**: ECV demands adding a new class for a new varying concept.
-  * [[Keep It Simple Stupid]] (KISS): ECV demands adding a new class for a new varying concept. This adds complexity. +  * [[Model Principle]] (MP): ECV sometimes results in classes which do not correspond to a real-world concept in the sense of MP. A "concept that varies" can also be a technical concept.
-  * [[Model Principle]] (MP): ECV sometimes results in classes which do not correspond top a real-world concept in the sense of MP. A "concept that varies" can also be a technical concept.+
  
 ==== Complementary Principles ==== ==== Complementary Principles ====
  
-  * [[Dependency Inversion Principle]] (DIP): ECV may result in the creation of abstract classes (i.e. the concepts) and descendant concrete classes (i.e. the variations). DIP now tells that other classes should only depend on the abstractions.+  * [[Low Coupling]] (LC): ECV results in the creation of a new moduleWhen introducing such a new module, LC has to be adhered to.
   * [[Liskov Substitution Principle]] (LSP): ECV may result in the introduction of an abstract base class. Here it is important to get the abstraction right. Otherwise LSP may be violated.   * [[Liskov Substitution Principle]] (LSP): ECV may result in the introduction of an abstract base class. Here it is important to get the abstraction right. Otherwise LSP may be violated.
- +  * [[Generalization Principle]] (GP): Encapsulating a varying concept typically results in a more generally applicable solution. This is especially true when an abstract concept is encapsulated by introducing an interface or an abstract class. 
 +  * [[Dependency Inversion Principle]] (DIP): ECV may result in the introduction of an abstract base class. Here DIP demands that other classes should only depend on this new abstract base class and not on the concrete subclasses. 
 +  * [[Information Hiding/Encapsulation]] (IH/E): ECV tells that varying concepts should be encapsulated. IH/E then tells how encapsulation is done.
 ==== Principle Collections ==== ==== Principle Collections ====
  
Line 89: Line 100:
  
  
-===== Example =====+===== Examples =====
  
  
Line 102: Line 113:
   * Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides: //[[wp>Design Patterns|Design Patterns:   * Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides: //[[wp>Design Patterns|Design Patterns:
  Elements of Reusable Object-Oriented Software]]//  Elements of Reusable Object-Oriented Software]]//
-  * Bertrand Meyer: //[[wp>Object-Oriented Software Construction]]//, p. 57pp. +  * [[Single Responsibility Principle]] 
-  * Robert C. Martin: //Agile Software Development, Principles, Patterns, and Practices//, p. 99pp. +  * [[Open-Closed Principle]] 
-  * [[http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod|ButUncleBob: Principles of OOD]]+ 
 +===== Discussion ===== 
 + 
 +Discuss this wiki article and the principle on the corresponding [[talk:principles:Encapsulate the Concept that Varies|talk page]]
principles/encapsulate_the_concept_that_varies.txt · Last modified: 2021-10-18 21:31 by christian