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 [2021-09-02 12:37] – old revision restored (2021-05-11 21:58) 65.21.179.175 | principles:invariant_avoidance_principle [2021-09-02 12:37] – old revision restored (2021-05-11 21:58) 65.21.179.175 | ||
---|---|---|---|
Line 15: | Line 15: | ||
===== Description ===== | ===== Description ===== | ||
- | |||
- | Methods typically have preconditions. Something that has to be true prior to invoking the method so it can work properly. Typical cases are parameters that may not be '' | ||
- | |||
- | Furthermore there are (class) invariants, i.e. conditions that have to be true in all observable states during the whole lifetime of an object. Typical invariants are attributes that may not be '' | ||
- | |||
- | While preconditions and invariants are absolutely necessary, introducing further ones comes at a certain cost. | ||
- | |||
- | Not that this principle does not apply to loop invariants, control-flow invariants, etc. as there is normally no chance to avoid them. But there can be fewer or more class invariants depending on the solution. | ||
===== Rationale ===== | ===== Rationale ===== | ||
- | |||
- | A typical kind of defect is the violation of an invariant or a precondition. The more preconditions and invariants there are, the more possibilities there are to introduce defects. And according to [[Murphy' | ||
Line 77: | Line 67: | ||
* [[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 141: | Line 130: | ||
==== Example 3: C++ References ==== | ==== Example 3: C++ References ==== | ||
- | Compare | + | Sompare |
<code c++> | <code c++> | ||
Line 162: | Line 151: | ||
==== Example 4: DRY ==== | ==== Example 4: DRY ==== | ||
- | A class for [[wp> | + | A class for [[wp> |
- | + | ||
- | 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 | + | |
- | + | ||
- | + | ||
- | ==== 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. | + | |
===== 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: |
/ | / | ||
principles/invariant_avoidance_principle.txt · Last modified: 2021-10-18 21:53 by christian