Quel est le principe du moindre étonnement?

Dans la programmation, ce qu’on appelle le principe de moindre surprise? Comment ce concept est-il lié à la conception de bonnes API? Est-ce quelque chose qui ne s'applique qu'à la programmation orientée objet ou est-ce que cela imprègne également d'autres techniques de programmation? Est-ce lié au principe de "faire une seule chose dans votre méthode et bien le faire"?

Le principe de moindre étonnement s’applique à un large éventail d’activités de conception - et pas seulement à l’informatique (bien que c’est souvent là que les choses les plus étonnantes se produisent).

Considérons un ascenseur avec un bouton à côté qui dit "appeler". Lorsque vous appuyez sur le bouton, le publiphone sonne (plutôt que d'appeler l'ascenseur à cet étage). Cela serait considéré comme étonnant. Le bon modèle serait de placer le bouton d'appel à côté du téléphone plutôt que de l'ascenseur.

Ensuite, imaginez une page Web comportant une fenêtre contextuelle indiquant une erreur de style Windows avec un bouton «ok». Les utilisateurs cliquent sur le bouton "ok" en pensant que c'est pour le système d'exploitation et se dirigent vers une autre page Web. Cela étonne l'utilisateur.

Quand il s'agit d'une API ...

• Pensez à une méthode toString () qui, au lieu d’imprimer les champs, retourne "pour être implémentée".
• Une méthode equals () qui fonctionne avec des informations cachées.
• Parfois, les gens essayent d'implémenter une classe de liste triée en modifiant la méthode add pour qu'elle appelle ensuite sort () sur le tableau - ce qui est étonnant, car la méthode add est supposée être ajoutée à la liste - c'est particulièrement surprenant quand on récupère un objet List sans savoir que quelque part au fond, quelqu'un a violé le contrat d'interface.

Avoir une méthode qui fait une chose distincte contribue à la réduction de l’étonnement, mais ce sont des principes distincts dans la conception des API. Les quatre principes souvent qualifiés de "bonne conception d'API" sont (à partir de ce pdf - un exemple d'une telle présentation. Les liens à la fin de celui-ci sont de bonne lecture):

• Principe de responsabilité unique
• Principe ouvert fermé
• SEC
• Principe du moindre étonnement

Il est potentiellement surprenant que quelqu'un ait une classe qui essaie de tout faire - ou qui a besoin de deux classes pour faire la même chose. Il est également potentiellement surprenant que quelqu'un se mêle de manière étrange avec les éléments internes (les classes ouvertes de Ruby sont une source d'étonnement sans fin). Il est également étonnant de trouver deux méthodes qui font apparemment la même chose.

En tant que tel, le principe de moindre étonnement est à la base des autres conceptions d’API - mais il ne suffit pas, en soi, de dire simplement «n’a pas d’API étonnante».

Pour en savoir plus (du point de vue de l’interface utilisateur) - un blog de développeur IBM intitulé " L’utilisateur grincheux: le principe du moindre étonnement"

Le principe de moindre étonnement est lorsque, en tant que concepteur d'API, vous empêchez vos utilisateurs de dire WAT .

Quelques exemples d'étonnement dans différentes langues.

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

Et il y a beaucoup plus d'exemples dans divers langages et API. Votre travail en tant que rédacteur d’API consiste à empêcher cela. Les choses doivent être nommées et dactylographiées de manière à rendre évident le rôle d'un appel vers votre API. Inclure une documentation suffisante lorsque cela n'est pas possible.

En gros, si les utilisateurs doivent lire attentivement votre documentation pour savoir comment lire le code écrit pour votre API, vous le faites probablement mal.

Voici un exemple d '"étonnement" qui m'est arrivé récemment. Je me suis égaré sur la route, alors je me suis arrêté et un peu frénétiquement (j'ai été en retard), j'ai percé une intersection dans mon GPS. J'ai cliqué sur Go et remis les mains sur le volant - mais un avertissement fort (plein écran) l'avertissant que le GPS devait être mis à jour - m'a obligé à reconnaître.

Ma pensée était "tu rigoles? Tu me dis ça maintenant? Je dois retirer mes mains du volant pour le reconnaître?".

L'étonnement fait surface dans l'interface (généralement l'interface utilisateur, mais je suppose que cela pourrait également être une API qui se comporte de manière inattendue). Je dirais également qu’il se glisse sous l’interface, car il faut un logiciel sous-jacent bien conçu pour prendre en charge une interface véritablement bien conçue.