web-dev-qa-db-ja.com

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

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

designdesign-patternsobject-oriented
33
Geek

最小驚異の原則は、コンピューティングだけでなく、幅広い設計活動に適用できます（ただし、最も驚異的なことが発生することがよくあります）。

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

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

APIに関しては...

  • フィールドを出力する代わりに「実装される」ことを返すtoString（）メソッドについて考えてください。
  • 非表示の情報を処理するequals（）メソッド。
  • ときどき 後で配列のsort（）を呼び出すようにaddメソッドを変更して、ソートされたリストクラスを実装しようとします-これは add method が追加されることになっているため、驚くべきことですリスト-これは、内部のどこかで誰かがインターフェイスコントラクトに違反したことを知らずにListオブジェクトを取得した場合に特に驚くべきことです。

1つの明確なことを行うメソッドを持つことは、驚きの軽減に貢献しますが、これらはAPI設計における個別の原則です。 「優れたAPI設計」としてよく宣伝されている4つの原則は次のとおりです（from this pdf -このようなプレゼンテーションの1つのインスタンスのみ。この特定の1つの終わりにあるリンクは、読みやすくなります）：

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

そのため、最小の驚異の原則が他のAPI設計の基礎になっていますが、それだけでは、「驚異的なAPIがない」とだけでは不十分です。

さらに読む（UIの観点から）-というタイトルのIBM開発者ブログ 不機嫌なユーザー：最小驚きの原則

47
user40980

驚くべきことの原則は、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のために書かれたコードを読み取る方法を理解するためにドキュメントを徹底的に読まなければならない場合、おそらくそれは間違っています。

4
Earlz

これが最近私に起こった「驚き」の例です。私は道路で道に迷ったので、車を止めて、やたらと必死になって（遅れました）交差点をGPSに押し込みました。 [移動]をクリックして手をハンドルに戻しましたが、GPSを更新する必要があるという大きな（全画面）警告が表示されました-確認する必要があります。

私の考えは、「冗談ですか？今私に言っているのです。認めるには手を離す必要がありますか？」でした。

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

0
Dave Clausen