• Object-Oriented Design

• Murphy's Law (ML): ML states that an invariant will eventually be broken. So IAP is the application of ML to invariants.

• 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.

• 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.

Stub