principles:easy_to_use_and_hard_to_misuse
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
principles:easy_to_use_and_hard_to_misuse [2013-02-18 17:24] – external edit 127.0.0.1 | principles:easy_to_use_and_hard_to_misuse [2021-10-13 08:19] – old revision restored (2021-09-02 12:26) 194.209.25.108 | ||
---|---|---|---|
Line 19: | Line 19: | ||
===== Strategies ===== | ===== 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 [[Keep It Simple Stupid|KISS]]) | ||
- | * Use the same mechanisms wherever reasonably possible (see [[Uniformity Principle|UP]]) | ||
- | * Use consistent naming and models throughout the design (see [[Uniformity Principle|UP] and [[Model Principle|MP]]) | ||
- | * Avoid Preconditions (see [[Invariant Avoidance Principle]]) | ||
- | * ... | ||
- | |||
- | |||
- | ===== Caveats ===== | ||
- | |||
- | See section [[#contrary principles]]. | ||
Line 55: | Line 41: | ||
==== Specializations ==== | ==== Specializations ==== | ||
- | * [[Principle of Least Surprise]] (PLS): | + | * [[Principle of Least Surprise]] (PLS): |
- | * [[Uniformity Principle]] (UP): Uniform interfaces are easier to use than others. | + | |
==== Contrary Principles ==== | ==== Contrary Principles ==== | ||
Line 64: | Line 49: | ||
==== Complementary Principles ==== | ==== Complementary Principles ==== | ||
- | * [[Model Principle]] (MP): An interface that is crafted according to the model is easier to use than one that is not. | + | * [[Model Principle]] |
+ | * [[Uniformity Principle]] | ||
+ | * [[Fail Fast]] (FF): | ||
* [[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. | * [[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/ | ||
==== Principle Collections ==== | ==== Principle Collections ==== | ||
Line 85: | Line 71: | ||
* [[http:// | * [[http:// | ||
* [[http:// | * [[http:// | ||
- |
principles/easy_to_use_and_hard_to_misuse.txt · Last modified: 2021-10-18 21:29 by christian