principles:generalization_principle
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
principles:generalization_principle [2012-12-07 13:41] – DRY is superclass of GP! christian | principles:generalization_principle [2021-10-20 21:20] (current) – +++ restored +++ christian | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Generalization Principle ====== | + | ====== Generalization Principle |
===== Variants and Alternative Names ===== | ===== Variants and Alternative Names ===== | ||
- | * Build Generality into Software | + | * Build Generality into Software(({{page> |
+ | * Abstractions Live Longer than Details(({{page> | ||
+ | * Rule of Power (RoP) | ||
===== Context ===== | ===== Context ===== | ||
* [[contexts: | * [[contexts: | ||
+ | * [[contexts: | ||
+ | * [[contexts: | ||
+ | * [[contexts: | ||
+ | * [[contexts: | ||
+ | |||
- | ===== Definition | + | ===== Principle Statement |
A generalized solution, that solves not only one but many problems, is better than a specific one. | A generalized solution, that solves not only one but many problems, is better than a specific one. | ||
Line 17: | Line 23: | ||
===== Description ===== | ===== Description ===== | ||
+ | There are various ways to make a solution more generally applicable. In the simplest form this can be done by introducing a method with appropriate parameters. Other possibilities are classes, parametric types, callbacks, hook methods, etc. | ||
+ | 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 ===== | ||
- | Specific solutions tend to be fragile. When requirements change, a specific solution might not fulfill them anymore. | + | Specific solutions tend to be fragile. When requirements change, a specific solution might not fulfill them anymore. |
+ | |||
+ | 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 ===== | ||
+ | * Make modules configurable at runtime or deployment time by using configuration files. | ||
+ | * Use parameterizable modules(method parameters, object attributes, parametric types, etc.) | ||
+ | * Use constants | ||
+ | * Find suitable abstractions | ||
+ | |||
+ | ===== Caveats ===== | ||
+ | |||
+ | Making a [[glossary: | ||
+ | |||
+ | Another problem is the [[anti-patterns: | ||
+ | |||
+ | See also section [[#contrary principles]]. | ||
===== Origin ===== | ===== Origin ===== | ||
- | FIXME | + | The term " |
+ | |||
+ | {{page> | ||
===== Evidence ===== | ===== Evidence ===== | ||
/* Comment out what is not applicable and explain the rest: */ | /* Comment out what is not applicable and explain the rest: */ | ||
- | [[wiki: | + | * [[wiki: |
- | / | + | |
- | / | + | /* |
- | / | + | /* |
+ | /* | ||
Line 40: | Line 69: | ||
==== Generalizations ==== | ==== Generalizations ==== | ||
- | |||
- | * [[principles: | ||
==== Specializations ==== | ==== Specializations ==== | ||
Line 48: | Line 75: | ||
==== Contrary Principles ==== | ==== Contrary Principles ==== | ||
- | * **[[principles:Keep It Simple Stupid]]** | + | * **[[Keep It Simple Stupid]] |
+ | * [[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' | ||
+ | * [[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> | ||
+ | {{page> | ||
- | ===== 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: | + | /*[[wiki: |
- | /*[[wiki: | + | [[wiki: |
/ | / | ||
Line 67: | Line 100: | ||
===== 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