最小の驚きの原理は何ですか？

プログラミングでは、最小原理の原理と呼ばれるものは何ですか？この概念は、優れたAPIの設計にどのように関係していますか？これはオブジェクト指向プログラミングのみに適用されるものですか、それとも他のプログラミング手法にも浸透していますか？これは、「メソッドで1つのことを実行し、それをうまく実行する」という原則に関連していますか？

最小驚tonの原理は、コンピューティングだけでなく、さまざまなデザインアクティビティに適用できます（ただし、多くの場合、最も驚くべきことが起こります）。

「呼び出し」というボタンが隣にあるエレベーターを考えてみましょう。ボタンを押すと、公衆電話が鳴ります（その階にエレベーターを呼び出すのではなく）。これは驚くべきことです。正しい設計は、エレベーターではなく電話の隣に呼び出しボタンを配置することです。

次に、「OK」ボタンが付いたウィンドウスタイルエラーを表示するポップアップウィンドウがあるWebページについて考えます。人々は「ok」ボタンをクリックして、それがオペレーティングシステム用であると考え、代わりに別のウェブページに移動します。これはユーザーを驚かせます。

APIに関しては...

• フィールドを出力する代わりに「実装される」ことを返すtoString（）メソッドについて考えてください。
• 隠された情報に対して機能するequals（）メソッド。
• 時にはので、驚くべきことである-人々はその後、アレイ上の（）ソート通話に追加する方法を変更することにより、ソートされたリストのクラスを実装しようとaddメソッドがリストに追加することになっている- 1バックListオブジェクトを取得したときに、これは驚くべきは特にあり奥深くのどこかで、インターフェイス契約に違反したという知識はありません。

1つの明確なことを行うメソッドを持つことは驚きの軽減に貢献しますが、これらはAPI設計の独立した原則です。「良いAPIデザイン」とよく言われる4つの原則は、次のとおりです（このPDFから-そのようなプレゼンテーションの1つの例にすぎません。

• 単一責任の原則
• オープンクローズド原則
• ドライ
• 最少の驚きの原則

誰かがすべてを実行しようとするクラスを持っているか、または1つのことを実行するために2つのクラスを必要とするのは驚くべきことです。同様に、誰かが内部で奇妙な方法で内部をいじるのは驚くべきことです（Rubyのオープンクラスは、終わりのない驚きの源であると思います）。同様に、明らかに同じことを行う2つの方法を見つけることも驚くべきことです。

そのため、最小限の驚きの原則は他の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に交差点を打ちました。[Go]をクリックしてホイールに手を戻しましたが、GPSを更新する必要があるという大きな（フルスクリーンの）警告が表示されたため、確認する必要がありました。

私の考えは、「冗談だろうか？今これを言っているのか？それを認めるにはハンドルから手を離す必要があるのか​​？」と思った。

インターフェースの驚異的な表面（通常はUIですが、予期しない方法で動作するAPIでもあると思います）。本当によく設計されたインターフェースをサポートするには、よく設計された基礎ソフトウェアが必要なので、インターフェースの下にも浸透すると言います。