User Tools

Site Tools


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((Alan M. David//201 Principles of Software Development//)) +  * Build Generality into Software(({{page>resources:201 Principles#reference}})) 
-  * Abstractions Live Longer than Details((Andrew Hunt and David Thomas//The Pragmatic Programmer//))+  * Abstractions Live Longer than Details(({{page>resources:The Pragmatic Programmer#reference}})
 +  * Rule of Power (RoP)
  
 ===== Context ===== ===== Context =====
Line 12: Line 13:
   * [[contexts:Architecture]]   * [[contexts:Architecture]]
   * [[contexts:User Interface Design]]   * [[contexts:User Interface Design]]
 +  * [[contexts:Implementation]]
 +
  
 ===== Principle Statement ===== ===== Principle Statement =====
Line 33: 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 =====
  
-Making a [[glossary:module]] (typically a layer, a subsystem or an API) too general leads to the [[wp>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.+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 [[wp>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.+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]]. See also section [[#contrary principles]].
Line 51: Line 54:
 The term "generalization principle" is proposed here. Nevertheless the value of generalized solutions is well known at least since: The term "generalization principle" is proposed here. Nevertheless the value of generalized solutions is well known at least since:
  
-David Parnas//Designing Software for Ease of Extension and Contraction//+{{page>resources:Designing Software for Ease of Extension and Contraction#reference}}
  
  
Line 97: 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.1630576081.txt.gz · Last modified: 2021-09-02 11:48 by 65.21.179.175