User Tools

Site Tools


principles:generalization_principle

This is an old revision of the document!


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

Caveats

Making a module (typically layer, a system 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.

Origin

FIXME

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.

Principle Collections

OOD Principle Language
General Principles
ML KISS MIMC DRY GP RoE
Modularization Principles
MP HC ECV
Module Communication Principles
TdA/IE LC DIP
Interface Design Principles
EUHM PLS UP
Internal Module Design Principles
IH/E IAP LSP PSU

Example

Description Status

Further Reading

principles/generalization_principle.1361272491.txt.gz · Last modified: 2013-05-20 12:46 (external edit)