Principle Statement :
In interface design, always do the least surprising thing. 😨
Description :
Never surprise the user. ❌
An interface should behave exactly as the user thinks it behaves. ✅
What surprises the user depends on the kind of interface and the type of user. 🖥
The central idea of PLS is to think about how the user would want to use the interface. 🤳🏻
Principle of least astonishment is when you, as an API designer, prevent your users from saying WAT. 😱
🔸🔹🔸🔹
Examples :
1️⃣ Consider an elevator with a button next to it that says "call". ☎️
When you press the button, the payphone phone rings (rather than calling the elevator to that floor). ❌
The correct design would be to put the call button next to the phone rather than the elevator. ⛓
2️⃣ Think of a web page that has popup window that shows a windows style error with an 'ok' button on it. 🆗
People click the 'ok' button thinking it is for the operating system and instead go to another web page. 🌐
This astonishes the user. 😦
3️⃣ The name of a function should reflect what it does. Otherwise, a user of the function will be unpleasantly surprised❗️
Bad :
int multiply(int a, int b)
{
return a + b;
}
Better :
int multiply(int a, int b)
{
return a * b;
}
🔹🔸🔹🔸
When it comes to an API ... 👾
• Think about a toString() method that instead of printing out the fields returns back "to be implemented". 🤥
• An equals() method that works on hidden information. 👁
• Sometimes people try to implement a sorted list class by changing the add method to call sort() on the array afterwards. 🗂
This astonishing because the add method is supposed to append to the list. 🗳
This is especially astonishing when one gets back a List object with no knowledge that somewhere deep inside, someone violated the interface contract. 🤔
Having a method that does one distinct thing contributes to reduction of astonishment. ✅
https://t.me/pgimg/115
〰〰〰〰〰〰
#Principle #PLS
@ProgrammingTip
