ブログトップ 記事一覧 ログイン 無料ブログ開設

Strategic Choice

2011-03-04

[]誰にとっての「利便性」か

Convenience Is not an -ility

Gregor Hohpe

誰にとっての「利便性」か

グレゴー・ホーぺ

どういうこと?

APIを作るとき、「それは使う側にとって便利だろうか?」という問いかけを忘れてはいけません。

たとえば?

parser.processNodes(text,false);

このコードが何を意味するのか、APIの内部の実装を知らない人には分かりません。ドキュメントを調べてわかればまだ良い方です。

このメソッドは、「実装する側にとっての利便性」を優先し、「呼び出す側にとっての利便性」が考慮されていません。「することはほとんど同じなのに、2種類の呼び出しを使うのは不便ではないか」というのは、呼び出す側にとって「不便」というのではなく、コードを書く側が、内容のほとんど同じメソッドを2つ書くのが「不便(面倒)」という意味なのです。

どうして?

APIを作るというのは、複雑な処理を隠蔽するということです。つまり、APIを作る側が、複雑な処理を隠すために、面倒な作業を引き受ける、というのが本質です。「利便性」をもたないと意味がありません。

どうすれば?

より良いAPIを作るには、APIを1つの言語だと考えます。

APIを表現力豊かな言語にするにはどうすればいいかを考えるのです。基本的な言語なら「意味のある問いを立て、それに答える」ということができれば十分ですが、APIはさらに上のレイヤーの言語にするのです。つまりAPIでは、1つの問いに対応する動詞、つまりメソッドが必ず1つとは限らない、ということです。

たとえば、

walk(true);

というようなコードを書かされるよりは、単に

run();

と書ける方が間違いなく使いやすいです。walkとrunは本質的には同じ動作で、ただスピードが違うだけとみなすこともできるのですが、言葉が2つある方が使う側にとっては便利です。

一つ一つ考え抜かれ、整合性と豊富なボキャブラリーを兼ね備えたAPIを上のレイヤーとして追加すれば、言語の表現力が高まり、コードも読みやすく、理解しやすくなります。

関連

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/asakichy/20110304/1299200379