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 revision Previous revision
Next revision
Previous revision
Next revision Both sides next revision
principles:encapsulate_the_concept_that_varies [2021-09-02 12:26]
65.21.179.175 old revision restored (2021-05-19 11:22)
principles:encapsulate_the_concept_that_varies [2021-09-02 19:36]
65.21.179.175 old revision restored (2021-05-11 21:52)
Line 21: Line 21:
 ===== Strategies ===== ===== Strategies =====
  
-  * Introduce a separate module for the concept that may change in the future. In that way the future change will only affect that particular module. If the varying concept is properly encapsulated, only this module will have to change. 
-  * Introduce an interface encapsulating the varying concept. The interface may be implemented differently by several classes and code that only relies on the interface can handle any class implementing the interface. In case of another variation, just another class has to be introduced and this class has to implement the interface. If the abstraction is done properly, no module has to change. 
-  * Introduce an abstract base class encapsulating the varying concept. This is basically the same as introducing an interface. But here, implementation can also be inherited. So common parts can remain in the abstract base class whereas only the actual variations are defined in the subclasses. By means of method overriding, the implementation of the base class methods can be changed without touching the base class directly. 
-  * Use design patterns. Several design patterns use the above techniques to encapsulate varying concepts. For example: 
-    * Abstract Factory: A family of objects changes. 
-    * Factory Method: The exact type of an object to create changes. 
-    * Adapter: The interface of a module changes. 
-    * Bridge: A concept varies in more than one aspect. 
-    * Decorator: The behavior of certain methods may need to be enhanced. 
-    * Iterator: The traversal algorithm of a structure changes. Or the structure itself changes resulting in the need for a different traversal algorithm. 
-    * Observer: The objects interested in a certain event may change. 
-    * State: The behavior in a certain state or the state machine (states and transitions) of a certain module changes. 
-    * Strategy: An algorithm changes. 
-    * Template Method: The concrete steps in an algorithms change. 
-    * Visitor: New operations have to be added to a given more or less static inheritance structure of classes. 
-    * ... 
  
 ===== Origin ===== ===== Origin =====
  
-Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: //[[wp>Design Patterns|Design Patterns: Elements of Reusable Object-Oriented Software]]// ("GoF book"), p. 29 
  
 ===== 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:Accepted]]: This principle was popularly described in the GoF book and can thus be regarded accepted. +  * [[wiki:Examined]] 
-  * [[wiki:Examined]]: Many of the patterns in the GoF book are precisely about encapsulating varying concepts. See strategies section. +  * [[wiki:Accepted]] 
- +  * [[wiki:Questioned]] 
-/*  * [[wiki:Questioned]]*/+*/
  
 ===== Relations to Other Principles ===== ===== Relations to Other Principles =====
Line 55: Line 38:
 ==== 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.+  * [[Generalization Principle]] 
 +  * [[Open-Closed Principle]] 
  
 ==== Specializations ==== ==== Specializations ====
  
-  * [[Single Responsibility Principle]] (SRP): A responsibility in the sense of SRP is defined as "a reason for change". This is a concept that varies over time. SRP tells that each module should have exactly one responsibility, i.e. the concept/responsibility should be encapsulated in that module. +  * [[Single Responsibility Principle]] (SRP): 
-  * [[Open-Closed Principle]] (OCP): The OCP demands encapsulating abstract concepts in base classes (or interfaces) in order to be able to enhance the module by subclassing which is possible without changing the previously written code. In this case several variations of a concept may exist in the code at the same time. There is always the abstract base class plus one or usually more concrete subclasses. So the OCP is about encapsulating abstract concepts that vary "in space".+
  
 ==== Contrary Principles ==== ==== Contrary Principles ====
  
   * [[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 top 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.
  
Line 71: Line 54:
  
   * [[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.   * [[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.
-  * [[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. 
  
  
Line 77: Line 59:
  
 {{page>collections:OOD Principle Language#Box}} {{page>collections:OOD Principle Language#Box}}
 +{{page>collections:SOLID#Box}} 
 +{{page>collections:Principles in "Object-Oriented Software Construction"#Box}}
  
 ===== Example ===== ===== Example =====
Line 91: Line 74:
  
   * 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]]//, p. 29
   * Bertrand Meyer: //[[wp>Object-Oriented Software Construction]]//, p. 57pp.   * Bertrand Meyer: //[[wp>Object-Oriented Software Construction]]//, p. 57pp.
   * Robert C. Martin: //Agile Software Development, Principles, Patterns, and Practices//, p. 99pp.   * Robert C. Martin: //Agile Software Development, Principles, Patterns, and Practices//, p. 99pp.
   * [[http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod|ButUncleBob: Principles of OOD]]   * [[http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod|ButUncleBob: Principles of OOD]]
principles/encapsulate_the_concept_that_varies.txt · Last modified: 2021-10-18 21:31 by christian