User Tools

Site Tools


principles:invariant_avoidance_principle

This is an old revision of the document!


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

Example

Description Status

Further Reading

principles/invariant_avoidance_principle.1630579070.txt.gz · Last modified: 2021-09-02 12:37 by 65.21.179.175