Який принцип найменшого здивування?

У програмуванні називається Принцип найменшого здивування? Як ця концепція пов'язана з розробкою хороших API? Це щось застосовне лише до об'єктно-орієнтованого програмування чи воно пронизує й інші методи програмування? Чи пов’язано це з принципом "робити одну річ у своєму методі та робити це добре"?

Принцип найменшого здивування застосовний до широкого спектру дизайнерської діяльності - і не тільки в обчислювальній техніці (хоча там часто трапляються найдивовижніші речі).

Розгляньте ліфт із кнопкою поруч із написом "дзвоніть". Коли ви натискаєте кнопку, таксофон дзвонить (а не викликає ліфт на той поверх). Це було б вражаючим. Правильною конструкцією було б поставити кнопку виклику поруч із телефоном, а не ліфтом.

Далі, придумайте веб-сторінку, яка містить спливаюче вікно, яке відображає помилку стилю Windows із кнопкою «ОК» на ній. Люди натискають кнопку "ОК", думаючи, що це для операційної системи, а замість цього переходять на іншу веб-сторінку. Це дивує користувача.

Що стосується API ...

• Подумайте про метод toString (), який замість роздруківки полів повертається назад "для реалізації".
• Метод equals (), який працює на прихованій інформації.
• Іноді люди намагаються реалізувати відсортований клас списку, змінивши метод додавання на виклик sort () в масиві після цього - що дивно, оскільки метод додавання повинен додаватися до списку - це особливо дивно, коли повертаєш об'єкт списку не знаючи, що десь глибоко всередині хтось порушив договір інтерфейсу.

Наявність методу, який робить одну чітку річ, сприяє зменшенню здивування, проте це окремі принципи в розробці API. Чотири принципи, які часто рекламуються як "хороший дизайн API", є (з цього файлу pdf - лише один екземпляр такої презентації. Посилання в кінці цього конкретного тексту дозволяють добре прочитати):

• Принцип єдиної відповідальності
• Відкритий принцип закритого типу
• СУХИЙ
• Принцип найменшого здивування

Для когось потенційно дивовижно мати клас, який намагається зробити все - або потрібні два класи, щоб зробити одну справу. Це також може бути дивовижним для когось возитись із внутрішніми, як незвично, під прикриттями (я вважаю, що відкриті класи в Рубі є джерелом нескінченного здивування). Також дивним є пошук двох методів, які, очевидно, роблять те саме.

Таким чином, принцип найменшого здивування лежить в основі інших розробок API - але він сам по собі недостатній, щоб просто сказати, "не майте дивовижного API".

Подальше читання (з точки зору користувальницького інтерфейсу) - блог розробників IBM під назвою Примхливий користувач: Принцип найменшого здивування

Принцип найменшого здивування - це коли ви, як дизайнер API, заважаєте своїм користувачам говорити WAT .

Деякі приклади здивування різними мовами.

var array=new string[]; 
var list=array as IList<string>; //this works... 
list.Add("foo"); //exception saying it's not supported

foo.Equals(bar); //will call overriden Equals method
foo == bar; //equivalent to above in everyway, except for it won't call overrides... unless you're dealing with a string

var d=DateTime.Today;
d.Add(new TimeSpan(36,0,0,0)); //add 36 days to datetime d
Console.Writeline(d); //will print todays date. WAT

//in javascript
var f=function(){
  return 
    10; 
} //will either throw a syntax error or return void, depending on your javascript runner

І ще багато прикладів на різних мовах та API. Ваше завдання письменника API - запобігти цьому. Речі повинні бути названі та набрані таким чином, щоб було очевидно, що буде робити дзвінок у ваш API. Додайте достатню документацію там, де це неможливо.

В основному, якщо людям доводиться ретельно читати вашу документацію, щоб зрозуміти, як читати код, написаний для вашого API, ви, ймовірно, робите це неправильно.

Ось приклад "здивування", яке трапилося зі мною нещодавно. Я заблукав у дорозі, тому натягнув на себе і дещо відчайдушно (я запізнився) пробив перехрестя в мій GPS. Я натиснув Go і поклав руки назад на колесо - але потім отримав гучне (на весь екран) попередження про те, що GPS повинен бути оновлений - вимагаючи від мене підтвердження.

Моя думка полягала в тому, що "ти жартуєш? Ти зараз це мені кажеш? Мені потрібно зняти руки з колеса, щоб визнати?".

Подив поверхонь в інтерфейсі (як правило, інтерфейс користувача, але я вважаю, що це також може бути API, який веде себе несподівано). Я б сказав, що він пронизаний і нижче інтерфейсу, тому що він потребує добре розробленого базового програмного забезпечення для підтримки дійсно добре розробленого інтерфейсу.