Was ist das Prinzip des geringsten Erstaunens?

Was wird beim Programmieren als Prinzip des geringsten Erstaunens bezeichnet? In welcher Beziehung steht dieses Konzept zum Entwerfen guter APIs? Gilt dies nur für die objektorientierte Programmierung oder durchdringt es auch andere Programmiertechniken? Hängt dies mit dem Prinzip zusammen, "eine einzige Sache in Ihrer Methode zu tun und es gut zu machen"?

Das Prinzip des geringsten Erstaunens lässt sich auf eine Vielzahl von Designaktivitäten anwenden - und zwar nicht nur im Computerbereich (obwohl dort oft die erstaunlichsten Dinge passieren).

Stellen Sie sich einen Aufzug mit einem Knopf daneben vor, auf dem "Ruf" steht. Wenn Sie die Taste drücken, klingelt das Münztelefon (anstatt den Aufzug in diese Etage zu rufen). Das wäre erstaunlich. Das richtige Design wäre, die Anruftaste neben dem Telefon und nicht neben dem Aufzug zu platzieren.

Stellen Sie sich als Nächstes eine Webseite mit einem Popup-Fenster vor, in dem ein Windows-Stilfehler mit der Schaltfläche "OK" angezeigt wird. Die Benutzer klicken auf die Schaltfläche "OK" und gehen stattdessen auf eine andere Webseite. Dies überrascht den Benutzer.

Wenn es um eine API geht ...

• Stellen Sie sich eine toString () -Methode vor, bei der die Felder nicht gedruckt, sondern "implementiert" werden.
• Eine equals () -Methode, die verborgene Informationen verarbeitet.
• Manchmal wird versucht, eine sortierte Listenklasse zu implementieren, indem die Methode add dahingehend geändert wird, dass im Array anschließend sort () aufgerufen wird. Dies ist erstaunlich, da die Methode add an die Liste angehängt werden soll. Dies ist insbesondere dann erstaunlich, wenn ein List-Objekt zurückgegeben wird Ohne zu wissen, dass irgendwo tief im Inneren jemand den Schnittstellenvertrag verletzt hatte.

Eine Methode zu haben, die eine bestimmte Aufgabe erfüllt, trägt zur Verringerung des Erstaunens bei. Dies sind jedoch separate Prinzipien beim API-Design. Die vier Prinzipien, die oft als "gutes API-Design" angepriesen werden, lauten (aus diesem PDF - nur eine Instanz einer solchen Präsentation. Die Links am Ende dieser speziellen sorgen für eine gute Lektüre):

• Prinzip der Einzelverantwortung
• Offenes geschlossenes Prinzip
• TROCKEN
• Grundsatz des geringsten Erstaunens

Es ist möglicherweise erstaunlich, dass jemand eine Klasse hat, die versucht, alles zu tun - oder zwei Klassen braucht, um eine einzige Sache zu tun. Es ist ebenfalls möglicherweise erstaunlich, dass sich jemand unter der Decke auf seltsame Weise mit den Interna herumtreibt (ich finde, dass der offene Unterricht in Ruby eine Quelle für immerwährendes Erstaunen ist). Es ist auch erstaunlich, zwei Methoden zu finden, die anscheinend dasselbe tun.

Als solches liegt den anderen API-Designs das Prinzip des geringsten Erstaunens zugrunde - aber es reicht nicht aus, einfach zu sagen, dass es keine erstaunliche API gibt.

Lesen Sie weiter (aus der Sicht der Benutzeroberfläche) - ein IBM-Entwicklerblog mit dem Titel Der launische Benutzer: Das Prinzip des geringsten Erstaunens

Das Prinzip der geringsten Überraschung ist, wenn Sie als API-Designer Ihre Benutzer daran hindern, WAT zu sagen .

Einige Beispiele für Erstaunen in verschiedenen Sprachen.

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

Und es gibt noch viele weitere Beispiele in verschiedenen Sprachen und APIs. Ihre Aufgabe als API-Writer ist es, dies zu verhindern. Dinge sollten so benannt und getippt werden, dass es offensichtlich ist, was ein Aufruf Ihrer API bewirkt. Fügen Sie eine umfangreiche Dokumentation bei, wenn dies nicht möglich ist.

Grundsätzlich machen Sie es wahrscheinlich falsch, wenn die Leute Ihre Dokumentation gründlich lesen müssen, um herauszufinden, wie Code, der für Ihre API geschrieben wurde, gelesen werden kann.

Hier ist ein Beispiel für "Erstaunen", das mir kürzlich widerfahren ist. Ich habe mich auf der Straße verlaufen, bin also überfahren und habe etwas verzweifelt (ich war spät dran) eine Kreuzung in mein GPS geschlagen. Ich klickte auf Los und legte meine Hände wieder auf das Lenkrad. Dann wurde laut (im Vollbildmodus) gewarnt, dass das GPS aktualisiert werden sollte. Ich musste das bestätigen.

Mein Gedanke war: "Machst du Witze? Sagst du mir das jetzt? Ich muss meine Hände vom Lenkrad nehmen, um das zu bestätigen?".

Erstaunen taucht in der Benutzeroberfläche auf (normalerweise in der Benutzeroberfläche, aber ich nehme an, es könnte sich auch um eine API handeln, die sich unerwartet verhält). Ich würde sagen, es dringt auch unter die Benutzeroberfläche ein, da eine gut gestaltete zugrunde liegende Software erforderlich ist, um eine wirklich gut gestaltete Benutzeroberfläche zu unterstützen.