Principles Wiki

User Tools

Site Tools

You are here: Principles Wiki » Principles » Generalization Principle (GP)
principles:generalization_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:generalization_principle [2021-09-02 11:48] – old revision restored (2021-05-19 10:31) 65.21.179.175principles:generalization_principle [2021-10-20 21:20] (current) – +++ restored +++ christian
Line 3: Line 3:
 ===== Variants and Alternative Names ===== ===== Variants and Alternative Names =====
  
-  * Build Generality into Software +  * Build Generality into Software(({{page>resources:201 Principles#reference}})) 
 +  * Abstractions Live Longer than Details(({{page>resources:The Pragmatic Programmer#reference}})) 
 +  * Rule of Power (RoP)
  
 ===== Context ===== ===== Context =====
  
   * [[contexts:Object-Oriented Design]]   * [[contexts:Object-Oriented Design]]
 +  * [[contexts:API Design]]
 +  * [[contexts:Architecture]]
 +  * [[contexts:User Interface Design]]
 +  * [[contexts:Implementation]]
 +
  
 ===== Principle Statement ===== ===== Principle Statement =====
Line 21: Line 27:
 A general solution abstracts from the specific tasks and solves a superset of them. Parameterization of some kind is used to specify what has to be done in a given situation. A general solution abstracts from the specific tasks and solves a superset of them. Parameterization of some kind is used to specify what has to be done in a given situation.
  
 +A module can be more general than another one. But there are two aspects of this: First of all there is functionality. If module ''A'' can do the same as module ''B'' plus something more then ''A'' is more general. The second aspect is the one of what has to be done in order to exploit the generality. An ideal case would be that nothing has to be done and the module just does more. Other possibilities are that a configuration file has to be changed, an attribute has to be set, an invocation parameter has to be adjusted, etc. The least general possibility would be a module which can be changed easily. This is still better than a rigid module but less general than modules which do not need such changes. This form of generality is often rather called "flexibility" (({{page>resources:Designing Software for Ease of Extension and Contraction#reference}})).
 ===== Rationale ===== ===== Rationale =====
  
Line 30: Line 36:
  
 ===== Strategies ===== ===== Strategies =====
- +  * Make modules configurable at runtime or deployment time by using configuration files. 
-  * Use parameterizable modules+  * Use parameterizable modules(method parameters, object attributes, parametric types, etc.) 
 +  * Use constants
   * Find suitable abstractions   * Find suitable abstractions
 +
 ===== Caveats ===== ===== Caveats =====
  
-See section [[#contrary principles]].+Making a [[glossary:module]] (typically a layer, a subsystem or an API) too general leads to the [[anti-patterns:inner-platform effect]]. This means that the module is so general that it mirrors the functionality of the underlying platform without adding a benefit but only complexity. 
 + 
 +Another problem is the [[anti-patterns:turing tarpit]]. This means that the module is so general that arbitrarily complex tasks can be performed but those of interest, meaning the rather simple tasks that occur over and over again, are also difficult to do. This is a violation of the [[Easy to Use and hard to Misuse|EUHM]] principle. 
 + 
 +See also section [[#contrary principles]].
  
  
 ===== Origin ===== ===== Origin =====
  
-FIXME+The term "generalization principle" is proposed here. Nevertheless the value of generalized solutions is well known at least since: 
 + 
 +{{page>resources:Designing Software for Ease of Extension and Contraction#reference}} 
  
 ===== Evidence ===== ===== Evidence =====
Line 61: Line 76:
  
   * **[[Keep It Simple Stupid]] (KISS)**: A generalized solution is typically not simple anymore. This is the typical conflict between generality and simplicity.   * **[[Keep It Simple Stupid]] (KISS)**: A generalized solution is typically not simple anymore. This is the typical conflict between generality and simplicity.
 +  * [[Easy to Use and Hard to Misuse]] (EUHM): Too general solutions may lead to complicated usage of the module. 
 +  * [[Rule of Explicitness]] (RoE): RoE often results in specific solutions. Generality often requires stating something implicitly.
 ==== Complementary Principles ==== ==== Complementary Principles ====
  
Line 72: Line 88:
 {{page>collections:Principles in "The Pragmatic Programmer"#Box}} {{page>collections:Principles in "The Pragmatic Programmer"#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]]*/
  
Line 84: Line 100:
 ===== Further Reading ===== ===== Further Reading =====
  
-  * + 
 + 
 +===== Discussion ===== 
 + 
 +Discuss this wiki article and the principle on the corresponding [[talk:principles:Generalization Principle|talk page]].
  
principles/generalization_principle.1630576082.txt.gz · Last modified: by 65.21.179.175