User Tools

Site Tools


principles:invariant_avoidance_principle

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
principles:invariant_avoidance_principle [2021-09-02 20:09]
65.21.179.175 old revision restored (2021-03-27 09:33)
principles:invariant_avoidance_principle [2021-10-18 21:53] (current)
christian +++ restored +++
Line 1: Line 1:
-====== Invariant Avoidance Principle ======+====== Invariant Avoidance Principle (IAP) ======
  
 ===== Variants and Alternative Names ===== ===== Variants and Alternative Names =====
Line 6: Line 6:
 ===== Context ===== ===== Context =====
 /* fill in contexts here: */ /* fill in contexts here: */
-  * [[contexts:Object-Oriented Design]]  +  * [[contexts:Object-Oriented Design]]
  
 ===== Principle Statement ===== ===== Principle Statement =====
Line 15: Line 14:
  
 ===== 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 ''null'' or have to be in a certain range. A solution is better the fewer preconditions there are.
 +
 +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 ''null'' or have to be in a certain range, lists that have to contain certain objects with certain properties, etc. A solution is better the fewer invariants there are.
 +
 +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's Law]] these possibilities will sooner or later result in defects. So it is better to avoid preconditions and invariants as this reduces the number of potential faults in the software.
  
  
Line 38: Line 47:
 ===== Origin ===== ===== Origin =====
  
-This principle is newly introduced here.+{{page>resources:A Principle Language for Object-Oriented Design#reference}}
  
  
Line 67: Line 76:
  
   * [[Information Hiding/Encapsulation]] (IH/E): When an invariant cannot be avoided, it should at least be encapsulated.   * [[Information Hiding/Encapsulation]] (IH/E): When an invariant cannot be avoided, it should at least be encapsulated.
-  * [[Liskov Substitution Principle]] (LSP): Invariants can also be broken by subtypes. LSP tells that invariants may only be strengthened by subtypes, so they are not brokenFIXME+  * [[Liskov Substitution Principle]] (LSP): Not only the pure number and strength of invariants is relevant. The question is also which types in an inheritance hierarchy should have which invariants. Deriving ''Square'' from ''Rectangle'' for example adds an invariant in the subclass. LSP adds another point of view to this problem (see also [[glossary:rectangle-square problem]]).
   * [[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't Repeat Yourself]] (DRY): Duplication of information, like having the same data in different representations or like caching values, creates invariants. So an invariant sometimes is a hidden DRY violation.   * [[Don't Repeat Yourself]] (DRY): Duplication of information, like having the same data in different representations or like caching values, creates invariants. So an invariant sometimes is a hidden DRY violation.
 +  * [[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 130: Line 140:
 ==== Example 3: C++ References ==== ==== Example 3: C++ References ====
  
-Sompare the following two methods:+Compare the following two methods:
  
 <code c++> <code c++>
Line 151: Line 161:
 ==== Example 4: DRY ==== ==== Example 4: DRY ====
  
-A class for [[wp>complex numbers]] should either store the real and the imaginary part or absolute value and argument but not both. The values which are not stored can be computed in the getter method.+A class for [[wp>complex numbers]] should either store the real and the imaginary part or absolute value and argument but not both. If both are stored, there is the invariant that both representations result in the same complex number. 
 + 
 +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.
  
  
 ===== 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:Stub]]+/*[[wiki:Stub]]*/
 /*[[wiki:Incomplete]]*/ /*[[wiki:Incomplete]]*/
-/*[[wiki:Complete]]*/+[[wiki:Complete]]
  
 ===== Further Reading ===== ===== Further Reading =====
  
 +  * {{page>resources:A Principle Language for Object-Oriented Design#reference}}
 +
 +===== Discussion =====
 +
 +Discuss this wiki article and the principle on the corresponding [[talk:principles:Invariant Avoidance Principle|talk page]].
  
principles/invariant_avoidance_principle.1630606186.txt.gz · Last modified: 2021-09-02 20:09 by 65.21.179.175