ミニマルインターフェース

ミニマルインターフェースとは、API設計の一種で、ここではHumaneInterfaceと対比させます。ミニマルインターフェースの考え方は、クライアントが必要なことをすべて行えるAPIを設計することですが、その機能を、その作業を行うために最小限必要かつ妥当なメソッドセットにまで削減します。（違いの例はHumaneInterfaceを参照してください。）

HumaneInterfaceのruby-array/java-listの例を使用して、インデクサーとlengthメソッドがすでに存在するリストクラスにfirstメソッドとlastメソッドを含めないのは、既存のインターフェースを使用してfirstとlastを実行できるからです。その結果、firstとlastは利便性メソッドになります。ミニマリストはすべての利便性メソッドを回避するわけではありませんが、利便性メソッドは採用される基準が高くなります。

HumaneInterfaceの議論があれば、ミニマルインターフェースの根拠がここにあります。

インターフェース学習には時間がかかります。インターフェースが巨大なクラスは適切に使用される可能性が低く、そもそも敬遠される可能性があります。少数の焦点を絞ったメソッドセットを使用することで、クライアントはクラスが何であるか、何をできるかを見つけやすくなります。

このフォーカスは、クラス設計者にとっても重要です。クラス設計の一般的な問題は、クラスにあまりにも多くのことをさせることです。本質に焦点を当てることで、クラスから無駄なものを取り除き、1つのタスクのみを行い、それを適切に行えるようにします。

人間中心的なアプローチに従うと、どこで停止するべきかがわかりますか？誰かが望んでいる可能性があるためメソッドをいつまでも追加し続けると、メソッドに終わりがなくなります。そのため、メソッドの急増を防ぐためにいくつかのガイドラインが必要です。人間中心的なガイドライン（有益なものとして提供する）は、恣意的で適用が困難です。ミニマリストのガイドラインはシンプルです。クライアントが既存のメソッドを使用して実行できる場合、追加のメソッドは必要ありません。

(この、有用なものを見つけるという問題は、アプリケーションコードよりも、公開されたクラスライブラリを作成している人のほうが問題になります。アプリケーションコードでは、用途がわかっています。クローズドシステムです。）

静的に型付けされた純粋なインターフェース（JavaとC#のinterfaceキーワードなど）を使用している場合、メソッド数を少なくするもう1つの理由は、インプリメンターの負担を軽減することです。多数のメソッドをすべて実装する必要があり、これは多くの作業です。（ミックスインとして抽象クラスを使用すると、この負担を軽減できます。）

ミニマルクラスでより多くの機能が必要な場合は、他のクラスを使用できます。たとえば、Javaでは、RubyのArrayの通常のメソッドであるリストを逆順に並べ替えたりソートしたりする場合、Collectionsユーティリティクラスを使用します。

ライブラリを使用する場合、公開すると、何かを取り出すのは非常に困難です。そのため、あまりにも大きいものを持って、削除できない場合よりも、小さすぎるものから始めて、追加するほうがよいでしょう。