Qual è il principio del minimo stupore?

Il Principio di Minore Stimolazione è applicabile a una vasta gamma di attività di progettazione - e non solo nel calcolo (anche se è spesso dove accadono le cose più sorprendenti).

Considera un ascensore con un pulsante accanto ad esso che dice "chiama". Quando si preme il pulsante, il telefono pubblico squilla (anziché chiamare l'ascensore per quel piano). Questo sarebbe considerato sorprendente. Il design corretto sarebbe quello di mettere il pulsante di chiamata accanto al telefono piuttosto che l'ascensore.

Quindi, pensa a una pagina web che ha una finestra pop-up che mostra un errore di stile di Windows con un pulsante 'ok' su di esso. Le persone fanno clic sul pulsante "ok" pensando che sia per il sistema operativo e invece passino a un'altra pagina web. Questo stupisce l'utente.

Quando si tratta di un'API ...

• Pensa a un metodo toString () che invece di stampare i campi ritorna indietro "per essere implementato".
• Un metodo equals () che funziona su informazioni nascoste.
• A volte le persone cercano di implementare una classe di elenchi ordinati cambiando il metodo di aggiunta chiamare sort () sull'array in seguito, il che è sorprendente perché aggiungi metodo dovrebbe aggiungere alla lista - questo è particolarmente sorprendente quando si ottiene un oggetto List senza alcuna conoscenza che da qualche parte nel profondo, qualcuno ha violato il contratto di interfaccia.

Avere un metodo che fa una cosa distinta contribuisce alla riduzione dello stupore, tuttavia questi sono principi separati nella progettazione dell'API. I quattro principi spesso propagandati come "buona progettazione API" sono (da questo pdf - solo una istanza di tale presentazione I collegamenti alla fine di questo particolare danno una buona lettura):

• Principio di responsabilità singola
• Apri principio chiuso
• ASCIUGA
• Principio di minimo stupore

È potenzialmente sorprendente per qualcuno avere una classe che cerca di fare tutto - o che ha bisogno di due classi per fare una singola cosa. Allo stesso modo è potenzialmente sorprendente che qualcuno faccia casino con gli interni in modi strani sotto le copertine (trovo che le classi aperte in Ruby siano fonte di stupore infinito). Allo stesso modo è sorprendente trovare due metodi che fanno apparentemente la stessa cosa.

In quanto tale, il principio del minimo stupore è alla base degli altri progetti API - ma, di per sé, non è sufficiente per dire semplicemente "non avere un'API sorprendente".

Ulteriore lettura (dal punto di vista dell'interfaccia utente) - un blog degli sviluppatori IBM intitolato L'utente irritabile : The Principle of Almstononation

Il principio di minore stupore è quando tu, come progettista API, impedisci ai tuoi utenti di dire WAT .

Alcuni esempi di stupore in varie lingue.

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

E ci sono molti altri esempi in varie lingue e API. Il tuo lavoro come scrittore API è per prevenire questo. Le cose dovrebbero essere nominate e digitate in modo tale che sia palesemente ovvio che cosa farà una chiamata alla tua API. Includi un'ampia documentazione laddove ciò non è possibile.

In sostanza, se le persone devono leggere attentamente la tua documentazione per capire come leggere il codice scritto per la tua API, probabilmente stai sbagliando.

Ecco un esempio di "stupore" che mi è successo di recente. Mi sono perso sulla strada, quindi ho tirato su e un po 'freneticamente (ero in ritardo) un incrocio nel mio GPS. Ho cliccato su Go e ho rimesso le mani sul volante, ma poi ho ricevuto un strong avviso (a schermo intero) che il GPS dovrebbe essere aggiornato, richiedendomi di confermare.

Il mio pensiero era "stai scherzando? mi stai dicendo questo ora? Ho bisogno di prendere le mie mani dal volante per riconoscere?".

Superfici di stupore nell'interfaccia (tipicamente l'interfaccia utente, ma suppongo che potrebbe anche essere un'API che si comporta in modo inaspettato). Direi che permea anche sotto l'interfaccia, perché richiede un software di base ben progettato per supportare un'interfaccia davvero ben progettata.