principles:invariant_avoidance_principle
This is an old revision of the document!
Table of Contents
Invariant Avoidance Principle
Variants and Alternative Names
Context
Principle Statement
Description
Rationale
Strategies
Caveats
See section contrary principles.
Origin
Evidence
Relations to Other Principles
Generalizations
- Murphy's Law (ML): ML states that an invariant will eventually be broken. So IAP is the application of ML to invariants.
Specializations
Contrary Principles
- 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
- 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 broken.
- 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
Example
Description Status
Further Reading
principles/invariant_avoidance_principle.1630579070.txt.gz · Last modified: 2021-09-02 12:37 by 65.21.179.175