principles:encapsulate_the_concept_that_varies
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:encapsulate_the_concept_that_varies [2013-01-30 15:02] – [Principle Collections] -OCP collections christian | principles:encapsulate_the_concept_that_varies [2020-10-12 16:09] – old revision restored (2013-03-18 09:44) 159.69.186.191 | ||
---|---|---|---|
Line 14: | Line 14: | ||
===== Description ===== | ===== Description ===== | ||
+ | |||
+ | This principle has two aspects that roughly correspond to the two sub-principles [[Single Responsibility Principle|SRP]] and [[Open-Closed Principle|OCP]]. The first one is about making changes local. Everything which is supposed to change in the future should be encapsulated in a single module. This means [[glossary: | ||
+ | |||
+ | The second aspect is about introducing abstractions. Sometime the varying concept is one which varies at runtime rather than by maintenance. So at runtime it is decided upon a certain variation or there can be even several variations at the same time. In this case there has to be an abstract base class or an interface which encapsulates the varying concept. Several concrete descendant classes then specify the concrete variation. | ||
+ | |||
+ | The difference between the two aspects is whether the varying concept is one that changes over time during maintenance or one that may change at runtime. Nevertheless the advice is the same: encapsulate the concept that varies. | ||
===== Rationale ===== | ===== Rationale ===== | ||
+ | |||
+ | There are two reasons for this principle. The first reason is locality. When a varying concept is properly encapsulated in a single module, only this module is affected in case of a change. This reduces maintenance effort and [[glossary: | ||
+ | |||
+ | The second reason comes to play when the varying concept is implemented as an abstract class or interface. In this case a variation can be introduced without changing existing and tested code. This reduces testing effort (as already tested code does not need to be retested as it is not changed) as well as ripple effects (as the enhancement is done simply by adding a class. Note that for this rationale to work, the [[Liskov Substitution Principle]] also has to be adhered to. | ||
Line 37: | Line 47: | ||
* Visitor: New operations have to be added to a given more or less static inheritance structure of classes. | * Visitor: New operations have to be added to a given more or less static inheritance structure of classes. | ||
* ... | * ... | ||
+ | |||
+ | ===== Caveats ===== | ||
+ | |||
+ | See section [[#contrary principles]]. | ||
+ | |||
===== Origin ===== | ===== Origin ===== | ||
Line 54: | Line 69: | ||
==== Generalizations ==== | ==== Generalizations ==== | ||
- | |||
- | * [[Generalization Principle]] (GP): 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. | ||
==== Specializations ==== | ==== Specializations ==== | ||
Line 64: | Line 77: | ||
==== Contrary Principles ==== | ==== Contrary Principles ==== | ||
- | * [[More Is More Complex]] (MIMC): ECV demands adding a new class for a new varying concept. | + | |
- | | + | |
* [[Model Principle]] (MP): ECV sometimes results in classes which do not correspond top a real-world concept in the sense of MP. A " | * [[Model Principle]] (MP): ECV sometimes results in classes which do not correspond top a real-world concept in the sense of MP. A " | ||
==== Complementary Principles ==== | ==== Complementary Principles ==== | ||
- | * [[Dependency Inversion Principle]] (DIP): ECV may result | + | * [[Low Coupling]] (LC): ECV results |
* [[Liskov Substitution Principle]] (LSP): ECV may result in the introduction of an abstract base class. Here it is important to get the abstraction right. Otherwise LSP may be violated. | * [[Liskov Substitution Principle]] (LSP): ECV may result in the introduction of an abstract base class. Here it is important to get the abstraction right. Otherwise LSP may be violated. | ||
- | + | * [[Generalization Principle]] (GP): 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. | |
+ | * [[Dependency Inversion Principle]] (DIP): ECV may result in the introduction of an abstract base class. Here DIP demands that other classes should only depend on this new abstract base class and not on the concrete subclasses. | ||
+ | * [[Information Hiding/ | ||
==== Principle Collections ==== | ==== Principle Collections ==== | ||
Line 79: | Line 92: | ||
- | ===== 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 92: | Line 105: | ||
* Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides: // | * Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides: // | ||
| | ||
- | * Bertrand Meyer: //[[wp> | + | * [[Single Responsibility Principle]] |
- | * Robert C. Martin: //Agile Software Development, | + | * [[Open-Closed Principle]] |
- | * [[http:// | + |
principles/encapsulate_the_concept_that_varies.txt · Last modified: 2021-10-18 21:31 by christian