principles:invariant_avoidance_principle
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:invariant_avoidance_principle [2013-03-07 17:57] – description, rationale, improved example 4 christian | principles:invariant_avoidance_principle [2021-09-02 12:37] – old revision restored (2021-03-27 09:52) 65.21.179.175 | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Invariant Avoidance Principle ====== | + | ====== Invariant Avoidance Principle |
===== Variants and Alternative Names ===== | ===== Variants and Alternative Names ===== | ||
Line 6: | Line 6: | ||
===== Context ===== | ===== Context ===== | ||
/* fill in contexts here: */ | /* fill in contexts here: */ | ||
- | * [[contexts: | + | * [[contexts: |
===== Principle Statement ===== | ===== Principle Statement ===== | ||
Line 48: | Line 47: | ||
===== Origin ===== | ===== Origin ===== | ||
- | This principle is newly introduced here. | + | {{page> |
Line 77: | Line 76: | ||
* [[Information Hiding/ | * [[Information Hiding/ | ||
- | * [[Liskov Substitution Principle]] (LSP): | + | * [[Liskov Substitution Principle]] (LSP): |
* [[Fail Fast]] (FF): Breaking an invariant is a defect. And in such a case the software should fail fast. | * [[Fail Fast]] (FF): Breaking an invariant is a defect. And in such a case the software should fail fast. | ||
* [[Don' | * [[Don' | ||
+ | * [[Low Coupling]] (LC): One type of precondition is that a specific method has to be called prior to another one. This also results in a temporal coupling. | ||
==== Principle Collections ==== | ==== Principle Collections ==== | ||
Line 140: | Line 140: | ||
==== Example 3: C++ References ==== | ==== Example 3: C++ References ==== | ||
- | Sompare | + | Compare |
<code c++> | <code c++> | ||
Line 164: | Line 164: | ||
So it is better to store just one representation (e.g. the real and imaginary values) and if the other representation is needed (in this case the polar form), it can be computed. This can also be done transparently in the getter method. | So it is better to store just one representation (e.g. the real and imaginary values) and if the other representation is needed (in this case the polar form), it can be computed. This can also be done transparently in the getter method. | ||
+ | |||
+ | |||
+ | ==== Example 5: Caching ==== | ||
+ | |||
+ | All forms of caching and redundancy are typical violations of IAP. They are done in order to increase performance. But there is always the disadvantage that all copies have to be kept in sync as there is the invariant that the data may not be inconsistent throughout the copies. There are forms of caching where temporary inconsistencies are tolerated. This is slightly better in terms of IAP but nevertheless there are these consistency constraints and there is the danger of violating them, so to some degree the disadvantage is always there. | ||
Line 169: | Line 174: | ||
/* Choose one of the following and comment out the rest: */ | /* Choose one of the following and comment out the rest: */ | ||
/ | / | ||
- | [[wiki: | + | /*[[wiki: |
- | /*[[wiki: | + | [[wiki: |
===== Further Reading ===== | ===== Further Reading ===== | ||
+ | * {{page> | ||
+ | |||
+ | ===== Discussion ===== | ||
+ | Discuss this wiki article and the principle on the corresponding [[talk: |
principles/invariant_avoidance_principle.txt · Last modified: 2021-10-18 21:53 by christian