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
Next revisionBoth sides next revision
principles:generalization_principle [2021-09-02 11:47] – old revision restored (2021-05-19 10:31) 65.21.179.175principles:generalization_principle [2021-09-02 11:48] – old revision restored (2021-05-12 02:05) 65.21.179.175
Line 1: Line 1:
-====== Generalization Principle ======+====== Generalization Principle (GP) ======
  
 ===== Variants and Alternative Names ===== ===== Variants and Alternative Names =====
  
-  * Build Generality into Software +  * Build Generality into Software((Alan M. David: //201 Principles of Software Development//)) 
 +  * Abstractions Live Longer than Details((Andrew Hunt and David Thomas: //The Pragmatic Programmer//))
  
 ===== Context ===== ===== Context =====
Line 10: Line 10:
   * [[contexts:Object-Oriented Design]]   * [[contexts:Object-Oriented Design]]
  
-===== Definition =====+===== Principle Statement =====
  
-A generalized solution, that solves not only one but many problems, is better than a specific one. A generalized solution shall solve 80% of many many problems, not 100% of only one problem.+A generalized solution, that solves not only one but many problems, is better than a specific one.
  
  
Line 27: Line 27:
  
 Moreover a generalized solution can be reused in a variety of other situations. A specific solution can only be reused when exactly the same requirements appear again. So a general solution is much more reusable. Moreover a generalized solution can be reused in a variety of other situations. A specific solution can only be reused when exactly the same requirements appear again. So a general solution is much more reusable.
 +
 +
 +===== Strategies =====
 +
 +  * Use parameterizable modules
 +  * Find suitable abstractions
 +
 +
 +===== 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.
 +
 +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.
 +
 +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: 
 + 
 +David Parnas: //Designing Software for Ease of Extension and Contraction// 
  
 ===== 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:Examined]]*/ + 
-/*[[wiki:Accepted]]*/ +/*  * [[wiki:Examined]]*/ 
-/*[[wiki:Questioned]]*/+/*  * [[wiki:Accepted]]*/ 
 +/*  * [[wiki:Questioned]]*/
  
  
Line 44: Line 63:
  
 ==== Generalizations ==== ==== Generalizations ====
- 
-  * [[principles:Don't Repeat Yourself]] (DRY): A more general solution avoids duplication. 
  
 ==== Specializations ==== ==== Specializations ====
Line 52: Line 69:
 ==== Contrary Principles ==== ==== Contrary Principles ====
  
-  * **[[principles:Keep It Simple Stupid]]** +  * **[[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 ====
 +
 +  * [[Don't Repeat Yourself]] (DRY): A more general solution avoids duplication.
 +  * [[Encapsulate the Concept that Varies]] (ECV): 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.
  
 ==== Principle Collections ==== ==== Principle Collections ====
  
 +{{page>collections:OOD Principle Language#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 72: Line 95:
  
   *    * 
 +
principles/generalization_principle.txt · Last modified: 2021-10-20 21:20 by christian