ヒューメインと最小

API設計のポリシーとして、

という対立する考え方がある。
前者はクライアントが必要な機能をすべて提供できるようAPIを設計するが、仕事を成し遂げるための必要最小限のメソッドしか提供しないという考え方。後者は、みんなが何をやりたいかを見つけ出し、何度も起きることを簡単に行えるためのインタフェースを設計する、さらに言えば「冗長でも使いやすく」がモットーである。

たとえば、Listの最後の項目を取得したい。下記1で可能だが、より明示的なAPI（下記2）を提供する。これがヒューメイン・インタフェースである。

aList.get(aList.size -1)
aList.last

ヒューメイン・インタフェース派の考え方はこうだ。

オブジェクトの強みの大部分は、その振る舞いにあるのであって、データにあるのではない。最小の機能しか提供しないのであれば、複数のクライアントがよくある同じようなコードを重複して書かなければならない。 flattenのようなメソッドがなかったら、再帰処理を大勢の人間が書かなければならないだろう。まあ、それほど難しいことではないかもしれない。だが、頻繁に使用するのになんでいちいち面倒くさいことをしなきゃいけないの？
lastのようにシンプルにできる場合でも、読み手はイディオムを覚えなければならない。どうしてそんな間接的なことをしなきゃいけないわけ？直接読めるメソッドがあるってのに？優れたソフトウェアはユーザのことを第一に考え、ユーザーの生活を楽にしようとする。ヒューメイン・インタフェースはこの原則に従っている。

それに対する最小インタフェース派の反論は、「複雑さの爆発」だ。

ヒューメイン手法を採用した場合、どこまでやればよいのだろうか？誰かが使いたいと言ってるから、といってどんどんメソッドを追加していけば、メソッドだらけになってしまうだろう。したがって、このようなメソッド爆発を避けるためのガイドラインが必要となる。ヒューメイン手法のガイドライン（何が有用なのかを教えてくれるもの）は、確定したものにはならないし、難しいものだろう。