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”?
32
Odpowiedzi:
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 ...
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ę):
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
źródło
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.
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.
źródło
DateTime
. Zakładam, że jest to obiekt niezmienny iAdd
zwraca nową instancję. Jest to dość powszechne.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.
źródło