最小惊讶的原理是什么？

在编程中，什么是最小惊讶原理？这个概念与设计好的API有什么关系？这是否仅适用于面向对象的编程，还是也渗透到其他编程技术中？这是否与“在您的方法中做一件事情并做好事”的原则有关？

最小惊讶原则适用于广泛的设计活动-不仅适用于计算（尽管通常发生最令人惊讶的事情）。

考虑一台电梯，旁边有一个按钮，上面写着“呼叫”。当您按下按钮时，公用电话响起（而不是将电梯叫到该楼层）。这将被认为是惊人的。正确的设计是将呼叫按钮放在电话旁边而不是电梯旁边。

接下来，考虑一个具有弹出窗口的网页，该弹出窗口显示带有“确定”按钮的Windows样式错误。人们以为适用于操作系统的方式单击“确定”按钮，然后转到另一个网页。这使用户感到惊讶。

关于API ...

• 考虑一个toString（）方法，而不是打印出字段将返回“要实现”。
• 一个对隐藏信息起作用的equals（）方法。
• 有时人们尝试通过更改add方法来在数组后调用sort（）来实现排序列表类-这是令人惊讶的，因为应该将add方法追加到列表上-当人们返回List对象时，这尤其令人惊讶不知道内部深处有人违反了接口合同。

拥有一种可以做一件独特的事情的方法有助于减少惊讶，但是这些都是API设计中的独立原理。通常被吹捧为“良好的API设计”的四项原则是（摘自该pdf文件 -仅是该演示文稿的一个实例。该特定文章末尾的链接有助于您更好地阅读）：

• 单一责任原则
• 开闭原则
• 干
• 最小惊讶原则

某人拥有一个尝试做所有事情的类，或者需要两个课来做一件事情，可能会令人惊讶。如果有人在幕后以奇怪的方式弄乱内部结构，这也可能令人惊讶（我发现Ruby中的开放类是永无止境的惊奇之源）。同样地，找到两种可以做同样事情的方法也是令人惊讶的。

因此，最小惊讶度原则是其他API设计的基础-但这本身不足以简单地说“没有令人惊讶的API”。

进一步阅读（从UI角度看）-IBM开发人员博客，题为“胡思乱想的用户：最小惊讶原则”

最小惊讶的原则是，作为API设计人员，您阻止用户说WAT。

各种语言令人惊讶的例子。

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

还有更多使用各种语言和API的示例。您作为API编写者的工作就是避免这种情况。事物的命名和类型应该以一种显而易见的方式来调用您的API。在不可能的地方提供足够的文档。

基本上，如果人们必须彻底阅读您的文档以弄清楚如何阅读为您的API编写的代码，则您可能做错了。

这是我最近发生的“惊讶”的例子。我在路上迷路了，因此停下来，有些疯狂（我来晚了），将路口打入GPS。我单击“转到”，然后将手放回方向盘上，但是随后发出响亮的（全屏）警告，提示应更新GPS，需要我确认。

我的想法是“您在开玩笑吗？您现在正在告诉我吗？我需要把手放开以确认吗？”。

界面中的惊讶表面（通常是UI，但我想它也可能是行为异常的API）。我要说的是，它也渗透到界面的下方，因为它需要精心设计的底层软件来支持真正精心设计的界面。