Differences

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

--- principles:invariant_avoidance_principle [2013-02-10 18:08] – [Generalizations] christian
+++ principles:invariant_avoidance_principle [2021-09-02 12:37] – old revision restored (2021-05-11 21:58) 65.21.179.175
@@ Line 19: / Line 19: @@
 ===== Strategies =====
+===== Caveats =====
+See section [[#contrary principles]].
@@ Line 37: / Line 42: @@
 ==== Generalizations ====
-  * [[Murphy's Law]] (ML)
+  * [[Murphy's Law]] (ML): ML states that an invariant will eventually be broken. So IAP is the application of ML to invariants.
 ==== Specializations ====
@@ Line 43: / Line 48: @@
 ==== Contrary Principles ====
-  * **[[principles:Keep It Simple Stupid]]**
+  * **[[Keep It Simple Stupid]] (KISS)**: Adding an invariant typically makes the code easier, as it can be assumed that the invariant holds. In fact that is often the very purpose if introducing invariants: Either they make the design easier or they are inevitable. Otherwise they should be avoided.
 ==== Complementary Principles ====
-  * [[principles:Information Hiding/Encapsulation]]
+  * [[Information Hiding/Encapsulation]] (IH/E): When an invariant cannot be avoided, it should at least be encapsulated.
-  * [[principles:Liskov Substitution Principle]]
+  * [[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 broken. FIXME
-  * [[principles: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.
 ==== Principle Collections ====