User Tools

Site Tools


principles:easy_to_use_and_hard_to_misuse

Easy To Use And Hard To Misuse (EUHM)

Variants and Alternative Names

Context

Principle Statement

A module shall be easy to use and hard to misuse.

Description

A module is easy to use when the obvious way of using it is correct, when following established conventions means to use it correctly and the identifier of the module hints the correct usage. A module is hard to misuse, if misusing it requires more work than correct usage and when the compiler signals wrong usages.

Rationale

This principle is common wisdom among API designers. APIs are used by many people and mainly by those who have not implemented the API. Few people read the documentation and will just try to use an API the obvious way. If the obvious way of using it is correct, if the API is easy to use, development will be more efficient. Furthermore if an API is hard to misuse, fewer mistakes will be made and which decreases the need for debugging and improves code quality.

The same reasoning holds for every module, not just APIs. There are always other developers who will use a module. Either team members or successors. Moreover after a while one will not remember the details of a module anymore, the difference between other people and oneself will vanish. This means EUHM not only holds for APIs and not only for interfaces provided to the other team members but it holds for every single module.

Strategies

This is a very general principle so there is a large variety of possible strategies to adhere more to this principle largely depending on the given design problem:

  • Make use of static typing, so the compiler will report faults
  • Make the interface simple, so there will be fewer usage defects (see KISS)
  • Use the same mechanisms wherever reasonably possible (see UP)
  • Use consistent naming and models throughout the design (see UP and MP)
  • Avoid Preconditions (see Invariant Avoidance Principle)

Caveats

See section contrary principles.

Origin

The precise origin of the principle is unknown.

Evidence

Relations to Other Principles

Generalizations

  • Murphy's Law (ML): Because of ML an interface should be crafted so it is easy to use and hard to misuse. EUHM is the application of ML to interfaces.

Specializations

Contrary Principles

  • Keep It Simple Stupid (KISS): Both principles, KISS and EUHM, are about simplicity. But while EUHM is about the simplicity of an interface, KISS is rather concerned with simplicity of the implementation. KISS is contrary in those cases where the solution which is easier to implement is not so easy to use or imposes further possibilities for misuse.

Complementary Principles

  • Model Principle (MP): An interface that is crafted according to the model is easier to use than one that is not.
  • Invariant Avoidance Principle (IAP): One reason for a possible misuse of a module is an invariant. For example there might be a method which takes a list and an index where the index has to be within the bounds of the list. Each of these invariants imposes further possibilities for misuse of the module. So it is better to avoid them.
  • Information Hiding/Encapsulation (IH/E): A module should be properly encapsulated in order to make it easy to use and hard to misuse.
  • Law of Leaky Abstractions (LLA): The more an abstraction leaks, the less it can be considered hard to misuse.

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

Examples

Description Status

Further Reading

Discussion

Discuss this wiki article and the principle on the corresponding talk page.

principles/easy_to_use_and_hard_to_misuse.txt · Last modified: 2013-08-04 14:18 by christian