http://martinfowler.com/bliki/MinimalInterface.html

最小インタフェースとはAPI設計のスタイルである。 ここでは、HumaneInterfaceと比較していく。 最小インタフェースの背景にある考えは、クライアントが必要な機能をすべて提供できるようAPIを設計するが、仕事を成し遂げるための必要最小限のメソッドしか提供しないというものである（両者の違いについての例がヒューメインインターフェイスにあるので参照のこと）。

ヒューメインインターフェイスの主張はそちらのページに書いている。 ここでは、最小インタフェースの根拠について述べていこう。

インタフェースの習得には時間がかかる。 膨大なインタフェースを持つクラスはうまく使われることが少ないため、 最初の段階ではインタフェースは少なくしたほうがよいだろう。 インタフェースを小さく保ち、それらのメソッドに集中することで、 クライアントは、そのクラスが何なのか、何ができるのを容易に把握することができる。

この集中は、クラス設計者にも重要なことである。 クラス設計では、クラスが大きくなりすぎるという問題がよく起こる。 本質的な部分に集中すればクラスをキレイに保つことができ、クラスはひとつのジョブに集中し、よりよく成し遂げることができる。

ヒューメイン手法を採用した場合、どこまでやればよいのだろうか？ 誰かが使いたいと言ってるから、といってどんどんメソッドを追加していけば、メソッドだらけになってしまうだろう。 したがって、このようなメソッド爆発を避けるためのガイドラインが必要となる。 ヒューメイン手法のガイドライン（何が有用なのかを教えてくれるもの）は、確定したものにはならないし、難しいものだろう。 一方、最小インタフェースのガイドラインはシンプルである。 「既存のメソッドをクライアントが使えるなら、メソッドは追加する必要はない。」

（ 補足しておくと、何が有用なのかを見出すという課題は、アプリケーションを作っている人の課題というよりは、公布される(published)クラスライブラリを作っている人の課題だ。というのも、 中身の分かるアプリケーションのコードは直接触ることができるからだ★ ——つまり、システムとして閉じているのだ。 ）

静的に型付けされたピュアなインタフェース（JavaやC#のinterfaceキーワードなど）を使っている場合、メソッドの数を最小に保つもうひとつの理由は、実装者の負担を軽減するというものである。 膨大なメソッドをすべて実装しなければならないとなると、作業量もハンパじゃなくなる。 （抽象クラスをmixinとして使えば、この負荷は軽減される）