Differences

This shows you the differences between two versions of the page.

--- principles:principle_of_least_surprise [2021-09-02 10:48] – old revision restored (2021-05-11 22:18) 65.21.179.175
+++ principles:principle_of_least_surprise [2021-09-02 14:16] – old revision restored (2021-05-11 22:18) 65.21.179.175
@@ Line 4: / Line 4: @@
   * Principle of Least Astonishment (PLA)
-  * May also be referred to as "rule" or "law" instead of "principle"
+  * May also be referred to as "Rule" or "Law" instead of "principle"
@@ Line 12: / Line 12: @@
-===== Principle Statement =====
+===== Definition =====
 > In interface design, always do the least surprising thing.((Eric S. Raymond: //[[http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2878339|The Art of Unix Programming: Rule of Least Surprise]]//))
@@ Line 22: / Line 22: @@
 ===== Rationale =====
-===== Strategies =====
-  * Separate methods that change an object (commands) from methods asking the object a question (queries) (see [[Command-Query Separation|CQS]])
-    * This especially means that a query method should not alter the observable object state
-  * Name all modules in a way that clearly communicates what the module is and does
-    * Names of classes shall be nouns representing a specific (real-world) concept (see [[Model Principle|MP]])
-    * Names of ''interfaces'' shall be adjectives describing a specific property. This typically results in names ending with -able
-    * Names of command methods shall be verbs (in imperative form)
-    * Names of query methods shall start with get- or is-
-    * Names of mathematical functions or the like shall be named by the respective concept (like ''sqrt'')
-    * ...
-  * Avoid "clever" solutions which are hard to grasp in favor of simple, dumb ones (see [[Keep It Simple Stupid|KISS]])
-    * [[When in doubt, use brute force]]((http://www.catb.org/~esr/writings/taoup/html/ch01s06.html))
-    * Tend to use the first solution that comes in mind
-===== Caveats =====
-See section [[#contrary principles]].
@@ Line 49: / Line 29: @@
 ===== Evidence =====
 /* Comment out what is not applicable and explain the rest: */
-/*
+/*[[wiki:Proposed]]
-  * [[wiki:Proposed]]
+[[wiki:Examined]]
-  * [[wiki:Examined]]
+[[wiki:Accepted]]
-  * [[wiki:Accepted]]
+[[wiki:Questioned]]*/
-  * [[wiki:Questioned]]
-*/
@@ Line 60: / Line 38: @@
 ==== Generalizations ====
-  * [[Easy to Use and Hard to Misuse]] (EUHM): A module is easy to use if there is no surprise in how it works.
 ==== Specializations ====
-  * [[Command-Query Separation]] (CQS)
 ==== Contrary Principles ====
 ==== Complementary Principles ====
-  * [[Fail Fast]] (FF): FF is about what a module should do in the case of error. PLS on the other hand is about how the module should behave normally. Furthermore it normally is not a surprise that a module fails when there is an error but a module that doesn't fail when it should, behaves strangely.
+  * [[principles:Rule of Repair]]
-  * [[Model Principle]] (MP): PLS is mainly about how module identifier and module behavior relate to each other. MP tells that modules named according to the model are least surprising.
+  * [[principles:High Cohesion]]
-  * [[Uniformity Principle]] (UP): When applying PLS, UP should also be considered for naming modules.
+  * [[principles:Postel's Law]]
 ==== Principle Collections ====
-{{page>collections:OOD Principle Language#Box}}
 {{page>collections:Unix Philosophy (Eric S. Raymond)#Box}}
-===== Examples =====
+===== Example =====
@@ Line 95: / Line 69: @@
   * [[wiki>PrincipleOfLeastAstonishment]]
   * Joshua Bloch: //[[http://www.infoq.com/presentations/effective-api-design|How to Design a Good API & Why it Matters]]//