# Meta

* still in an early stage

principles:invariant_avoidance_principle

This is an old revision of the document!

# Invariant Avoidance Principle

## Caveats

See section contrary principles.

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

### 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

OOD Principle Language
General Principles
ML KISS MIMC DRY GP RoE
Modularization Principles
MP HC ECV
Module Communication Principles
TdA/IE LC DIP
Interface Design Principles
EUHM PLS UP
Internal Module Design Principles
IH/E IAP LSP PSU