Каков принцип наименьшего удивления?

В программировании то, что называется принципом наименьшего удивления? Как эта концепция связана с разработкой хороших API? Это применимо только к объектно-ориентированному программированию или оно проникает и в другие методы программирования? Связано ли это с принципом «делать что-то в своем методе и делать это хорошо»?

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

Рассмотрим лифт с кнопкой рядом с ним, которая говорит «звонок». Когда вы нажимаете кнопку, звонит таксофон (вместо вызова лифта на этот этаж). Это будет считаться удивительным. Правильный дизайн будет помещать кнопку вызова рядом с телефоном, а не лифтом.

Затем представьте веб-страницу с всплывающим окном, в котором отображается ошибка стиля Windows с кнопкой «ОК». Люди нажимают кнопку «ОК», думая, что это для операционной системы, и вместо этого переходят на другую веб-страницу. Это удивляет пользователя.

Когда дело доходит до API ...

• Подумайте о методе toString (), который вместо распечатки полей возвращает обратно «для реализации».
• Метод equals (), который работает со скрытой информацией.
• Иногда люди пытаются реализовать класс отсортированного списка, изменяя метод add для вызова sort () для массива впоследствии - что удивительно, потому что метод add должен добавлять в список - это особенно удивительно, когда кто-то возвращает объект List не зная, что где-то глубоко внутри кто-то нарушил контракт интерфейса.

Наличие метода, который делает одну особую вещь, способствует снижению удивления, однако это отдельные принципы в дизайне API. Четырьмя принципами, часто называемыми «хорошим дизайном API», являются (из этого pdf - только один из примеров такой презентации. Ссылки в конце этой конкретной статьи предназначены для хорошего чтения):

• Принцип единой ответственности
• Открытый закрытый принцип
• DRY
• Принцип наименьшего удивления

Потенциально удивительно, что у кого-то есть класс, который пытается сделать все - или ему нужны два класса, чтобы сделать что-то одно. Также потенциально удивительно, что кто-то странным образом связывается с внутренностями под покровами (я считаю, что открытые классы в Ruby являются источником бесконечного удивления). Также удивительно найти два метода, которые делают одно и то же.

Как таковой, принцип наименьшего удивления лежит в основе других конструкций 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, который ведет себя неожиданным образом). Я бы сказал, что он распространяется и под интерфейсом, потому что для поддержки действительно хорошо спроектированного интерфейса требуется хорошо спроектированное базовое программное обеспечение.