Jaka jest zasada najmniejszego zdziwienia?

Co w programowaniu nazywa się zasadą najmniejszego zdziwienia? Jak ta koncepcja jest związana z projektowaniem dobrych interfejsów API? Czy dotyczy to tylko programowania obiektowego, czy też przenika inne techniki programowania? Czy ma to związek z zasadą „robienia jednej rzeczy w metodzie i robienia tego dobrze”?

Zasada najmniejszego zdziwienia ma zastosowanie do szerokiej gamy działań projektowych - i to nie tylko w informatyce (choć często zdarzają się najbardziej zadziwiające rzeczy).

Rozważ windę z przyciskiem obok, który mówi „zadzwoń”. Po naciśnięciu przycisku telefon zadzwoni (zamiast dzwonić do windy na to piętro). Można to uznać za zadziwiające. Prawidłowym rozwiązaniem byłoby umieszczenie przycisku połączenia obok telefonu zamiast windy.

Następnie pomyśl o stronie internetowej z wyskakującym oknem, które pokazuje błąd stylu okna z przyciskiem „ok”. Ludzie klikają przycisk „ok”, myśląc, że jest to system operacyjny, i zamiast tego przechodzą na inną stronę internetową. To zadziwia użytkownika.

Jeśli chodzi o interfejs API ...

• Pomyśl o metodzie toString (), która zamiast wypisywać pola zwraca „do zaimplementowania”.
• Metoda equals (), która działa na ukrytych informacjach.
• Czasami ludzie próbują zaimplementować posortowaną klasę listy, zmieniając następnie metodę add na wywołanie sort () w tablicy - co jest zadziwiające, ponieważ metoda add ma dołączyć się do listy - jest to szczególnie zdumiewające, gdy odzyskujemy obiekt List bez wiedzy, że gdzieś głęboko w środku ktoś naruszył umowę interfejsu.

Posiadanie metody, która robi jedną odrębną rzecz, przyczynia się do zmniejszenia zdziwienia, jednak są to odrębne zasady w projektowaniu API. Cztery zasady często reklamowane jako „dobry projekt API” to (z tego pliku pdf - tylko jeden przykład takiej prezentacji. Linki na końcu tej konkretnej stanowią dobrą lekturę):

• Zasada jednej odpowiedzialności
• Zasada otwartego zamkniętego
• SUCHY
• Zasada najmniejszego zdziwienia

Potencjalnie zadziwiające jest to, że ktoś ma klasę, która próbuje zrobić wszystko - lub potrzebuje dwóch klas do zrobienia jednej rzeczy. Potencjalnie zadziwiające jest to, że ktoś dziwnie zadziera z wnętrznościami pod przykryciem (uważam, że otwarte klasy w Ruby są źródłem niekończącego się zdziwienia). Zadziwiające jest również znalezienie dwóch metod, które najwyraźniej robią to samo.

Jako taka zasada najmniejszego zdziwienia leży u podstaw innych projektów API - ale sama w sobie nie wystarczy powiedzieć „nie ma zadziwiającego API”.

Dalsza lektura (z perspektywy interfejsu użytkownika) - blog programisty IBM zatytułowany Zepsuty użytkownik: zasada najmniejszego zdziwienia

Zasada najmniejszego zdziwienia polega na tym, że jako projektant interfejsu API uniemożliwiasz użytkownikom wymawianie WAT .

Kilka przykładów zdziwienia w różnych językach.

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

Istnieje wiele innych przykładów w różnych językach i interfejsach API. Twoim zadaniem jako twórcy API jest zapobieganie temu. Rzeczy powinny być nazwane i wpisane w taki sposób, aby oczywiste było, co zrobi wywołanie interfejsu API. Dołącz obszerną dokumentację, jeśli nie jest to możliwe.

Zasadniczo, jeśli ludzie muszą dokładnie przeczytać twoją dokumentację, aby dowiedzieć się, jak ODCZYTAĆ kod napisany dla twojego API, prawdopodobnie robisz to źle.

Oto przykład „zdziwienia”, które mi się ostatnio przydarzyło. Zgubiłem się na drodze, więc zatrzymałem się i nieco gorączkowo (spóźniłem się) wcisnąłem skrzyżowanie w GPS. Kliknąłem przycisk Go i ponownie położyłem ręce na kierownicy - ale wtedy usłyszałem głośne (na pełnym ekranie) ostrzeżenie, że GPS powinien zostać zaktualizowany - wymagając ode mnie potwierdzenia.

Myślałem: „żartujesz? Mówisz mi to teraz? Muszę zdjąć ręce z kierownicy, żeby to potwierdzić?”.

Zdziwienie pojawia się w interfejsie (zazwyczaj interfejs użytkownika, ale przypuszczam, że może to być również interfejs API, który zachowuje się w nieoczekiwany sposób). Powiedziałbym, że przenika również poniżej interfejsu, ponieważ wymaga dobrze zaprojektowanego oprogramowania do obsługi naprawdę dobrze zaprojektowanego interfejsu.