Qual è il principio del minimo stupore?

Nella programmazione di ciò che viene chiamato Principio di minimo stupore? In che modo questo concetto è legato alla progettazione di buone API? È qualcosa applicabile solo alla programmazione orientata agli oggetti o permea anche altre tecniche di programmazione? È legato al principio di "fare una sola cosa nel tuo metodo e farlo bene"?

Il principio del minimo stupore è applicabile a una vasta gamma di attività di progettazione - e non solo nel campo dell'informatica (anche se è spesso lì che accadono le cose più sorprendenti).

Prendi in considerazione un ascensore con un pulsante accanto che dice "chiama". Quando si preme il pulsante, il telefono squilla (anziché chiamare l'ascensore a quel piano). Questo sarebbe considerato sorprendente. Il design corretto sarebbe quello di mettere il pulsante di chiamata accanto al telefono anziché all'ascensore.

Quindi, pensa a una pagina web che ha una finestra pop-up che mostra un errore di stile Windows con un pulsante 'ok' su di esso. Le persone fanno clic sul pulsante "ok" pensando che sia per il sistema operativo e invece passano 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 "da implementare".
• Un metodo equals () che funziona su informazioni nascoste.
• A volte le persone cercano di implementare una classe di elenco ordinata modificando il metodo add per chiamare in seguito sort () sull'array - il che è sorprendente perché il metodo add dovrebbe essere aggiunto all'elenco - questo è particolarmente sorprendente quando si torna a un oggetto List senza sapere 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 delle API. I quattro principi spesso indicati come "buona progettazione API" sono (da questo pdf - solo un'istanza di tale presentazione. I collegamenti alla fine di questa particolare rendono una buona lettura):

• Principio della sola responsabilità
• Principio aperto chiuso
• ASCIUTTO
• Principio del minimo stupore

È potenzialmente sorprendente che qualcuno abbia una classe che cerca di fare tutto - o che abbia bisogno di due classi per fare una sola cosa. Allo stesso modo è potenzialmente sorprendente che qualcuno faccia casino con gli interni in modo strano sotto le coperte (trovo che le lezioni aperte in Ruby siano una fonte di infinito stupore). È anche sorprendente trovare due metodi che apparentemente fanno la stessa cosa.

Come 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".

Ulteriori letture (dal punto di vista dell'interfaccia utente): un blog per sviluppatori IBM intitolato The cranky user: The Principle of Least Stonishment

Il principio del minimo stupore è quando tu, come designer 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 compito come scrittore di API è di impedirlo. Le cose dovrebbero essere nominate e digitate in modo tale che sia palesemente ovvio cosa farà una chiamata alla tua API. Includi un'ampia documentazione laddove ciò non sia possibile.

Fondamentalmente, se le persone devono leggere attentamente la 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 mi sono fermato e in qualche modo freneticamente (ero in ritardo) ho perforato un incrocio nel mio GPS. Ho fatto clic su Vai e ho rimesso le mani sul volante, ma ho ricevuto un forte avviso (a schermo intero) che il GPS doveva essere aggiornato, richiedendomi di riconoscerlo.

Il mio pensiero era "stai scherzando? Me lo stai dicendo adesso? Devo togliere le mani dal volante per riconoscere?".

Lo stupore emerge nell'interfaccia (in genere 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é ci vuole un software sottostante ben progettato per supportare un'interfaccia davvero ben progettata.