This is an old revision of the document!
Table of Contents
Generalization Principle (GP)
Variants and Alternative Names
- Build Generality into Software
Context
Principle Statement
A generalized solution, that solves not only one but many problems, is better than a specific one.
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.
Rationale
Specific solutions tend to be fragile. When requirements change, a specific solution might not fulfill them anymore. In contrast to that a more general solution is more stable so there will be less need to change it.
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
Origin
Evidence
Relations to Other Principles
Generalizations
Specializations
Contrary Principles
- Keep It Simple Stupid (KISS): A generalized solution is typically not simple anymore. This is the typical conflict between generality and simplicity.
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.