principles:generalization_principle
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
principles:generalization_principle [2018-06-24 11:00] – christian | principles:generalization_principle [2020-10-12 14:20] – old revision restored (2013-05-19 22:09) 159.69.186.191 | ||
---|---|---|---|
Line 3: | Line 3: | ||
===== Variants and Alternative Names ===== | ===== Variants and Alternative Names ===== | ||
- | * Build Generality into Software(({{page> | + | * Build Generality into Software((Alan M. David: //201 Principles |
- | * Abstractions Live Longer than Details(({{page> | + | * Abstractions Live Longer than Details((Andrew Hunt and David Thomas: //The Pragmatic Programmer//)) |
- | * Rule of Power (RoP) | + | |
===== Context ===== | ===== Context ===== | ||
* [[contexts: | * [[contexts: | ||
- | * [[contexts: | ||
- | * [[contexts: | ||
- | * [[contexts: | ||
- | * [[contexts: | ||
- | |||
===== Principle Statement ===== | ===== Principle Statement ===== | ||
Line 27: | Line 21: | ||
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 '' | + | |
===== Rationale ===== | ===== Rationale ===== | ||
Line 36: | Line 30: | ||
===== Strategies ===== | ===== Strategies ===== | ||
- | * Make modules configurable at runtime or deployment time by using configuration files. | + | |
- | * Use parameterizable modules(method parameters, object attributes, parametric types, etc.) | + | * Use parameterizable modules |
- | * Use constants | + | |
* Find suitable abstractions | * Find suitable abstractions | ||
+ | |||
===== Caveats ===== | ===== Caveats ===== | ||
- | Making a [[glossary: | + | Making a [[glossary: |
- | Another problem is the [[anti-patterns: | + | 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]]. | See also section [[#contrary principles]]. | ||
Line 54: | Line 48: | ||
The term " | The term " | ||
- | {{page> | + | David Parnas: //Designing Software for Ease of Extension and Contraction// |
Line 100: | Line 94: | ||
===== Further Reading ===== | ===== Further Reading ===== | ||
+ | * | ||
- | |||
- | ===== Discussion ===== | ||
- | |||
- | Discuss this wiki article and the principle on the corresponding [[talk: |
principles/generalization_principle.txt · Last modified: 2021-10-20 21:20 by christian