A generalized solution, that solves not only one but many problems, is better than a specific one.
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
A can do the same as module
B plus something more then
A is more general. The second aspect is the one of what has to be done in order to exploit the generality. An ideal case would be that nothing has to be done and the module just does more. Other possibilities are that a configuration file has to be changed, an attribute has to be set, an invocation parameter has to be adjusted, etc. The least general possibility would be a module which can be changed easily. This is still better than a rigid module but less general than modules which do not need such changes. This form of generality is often rather called “flexibility” 3).
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.
Making a module (typically a layer, a subsystem or an API) too general leads to the 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 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 EUHM principle.
See also section contrary principles.
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
|Principles In "The Pragmatic Programmer"|
|Don't Repeat Yourself||Make It Easy To Reuse||Eliminate Effects Between Unrelated Things||Program Close To The Problem Domain||Keep Knowledge in Plain Text||Write Code That Writes Code|
|Crash Early||Use Assertions to Prevent the Impossible||Use Exceptions for Exceptional Problems||Finish What You Start||Minimize Coupling Between Modules||Configure, Don't Integrate|
|Put Abstractions In Code, Details In Metadata||Always Design for Concurrency||Separate Views From Models||Abstractions Live Longer than Details|