人間中心インターフェース

しばらくRubyのコミュニティに関わってきましたが、「人間中心インターフェース」という用語をかなり目にします。これは、Rubyistがクラスインターフェースを作成する際の姿勢の一部を表しており、API設計における2つの思想（もう一つは最小限のインターフェース）の間の興味深い対比を示していると思います。

人間中心インターフェースの本質は、人々が何をしたがっているのかを調べ、一般的なケースを非常に簡単に実行できるようにインターフェースを設計することです。

最小限のインターフェースとの明白な対比は、人間中心インターフェースははるかに大きくなる傾向があり、実際、人間中心インターフェースの設計者はインターフェースのサイズをあまり気にしません。これは、人間中心インターフェースを持つクラスが実装の点で必ずしも大きくなる必要があるという意味ではありません。両者の基本的な機能は多くの場合非常に似ています。

人間中心インターフェースと最小限のインターフェースの違いを見る良い方法は、JavaとRubyのリストコンポーネントを比較することです。Javaには、25個のインスタンスメソッドを宣言するインターフェース（java.util.List）があります。RubyにはArrayクラス（配列ではなくリストです）があり、78個のメソッドがあります。このサイズの差は、ここで異なるスタイルがあるという手がかりの一つです（ただし、その違いにはもっと多くの理由があります）。どちらのコンポーネントも基本的には同じサービスを提供しますが、Rubyの配列には多くの追加機能が含まれています。この機能はすべて、Javaの最小限のインターフェース上に構築できる比較的小さなものです。

違いを示すために小さな例を挙げてみましょう。リストの最後のアイテムを取得します。Javaではこれを実行するには

aList.get(aList.size -1)

Rubyではこれを実行するには

anArray.last

実際には、それ以上に驚くべきことです。RubyのArrayにはfirstメソッドもあるので、anArray[0]ではなくanArray.firstを使用できます。

より大規模な機能もあります。RubyのArrayには、ネストされた配列を取り、単一レベルに変換するflattenメソッドがあります。

irb> [1,2,[3,4,[5,6],7],8].flatten
=> [1, 2, 3, 4, 5, 6, 7, 8]

ここで重要なのは、lastのように単純なものからflattenのように複雑なものまで、このすべての機能は、リストクラスのサイズを増やすことなく、クライアント自身によって記述できるということです。ミニマリストは、これらの動作をサポートするために必要な最小限のメソッドに焦点を当てる傾向がありますが、人間中心インターフェースの設計者は、必要なメソッドを追加しようとします。これらの追加のメソッドは、多くの場合、便宜的なメソッドと呼ばれますが、ミニマリストはそれを賛辞とは考えていません。

これは、「人間中心インターフェースに追加するものを決定する基準は何ですか？」という疑問を投げかけます。誰かが望むものをすべて追加すると、非常に複雑なクラスになります。人間中心インターフェースの設計者は、クラスの最も一般的な使用方法を特定し、これらの使用方法を容易にするようにインターフェースを設計しようとします。

この原則は追加するメソッドに影響を与えるだけでなく、メソッドの命名方法にも影響を与えます。RubyConfで、田中明氏は、一般的なメソッドには短い名前を優先することの価値を指摘しました。これらはより頻繁に使用されるため、それらに慣れてきます。頻繁に使用すれば短い名前を覚えやすく、入力と読み取りの手間が省けるため、より便利になります。その例としては、一般的な日付形式のデフォルトの解析を行うDateTimeのparseメソッドと、任意の形式を受け取ることができるより柔軟なstrptimeメソッドがありますが、後者はあまり使用しません。

この命名の原則は、ミニマリストのアプローチと矛盾しません。実際、JavaのListインターフェースが登場したとき、レガシーのVectorのelementAtメソッドはgetに変更されました。

Rubyの人間中心インターフェースの哲学のもう一つの興味深い結果は、メソッド名のエイリアシングです。リストの長さを取得する場合、lengthとsizeのどちらを使用する必要がありますか？一部のライブラリでは一方を使用し、一部のライブラリでは他方を使用しますが、RubyのArrayにはどちらも含まれており、エイリアスとしてマークされているため、どちらの名前でも同じコードが呼び出されます。Rubyistの見解では、ライブラリが両方を持つ方が、ライブラリのユーザーにどちらを使用するかを覚えるように求めるよりも簡単です。

どちらのインターフェース設計スタイルが最適かについて、長く退屈なスレッドになる可能性があります。ここでは、人間中心インターフェースに有利な議論を要約してみます（反対側の意見については最小限のインターフェースを参照してください）。

オブジェクトの強みの多くは、データではなく動作にあります。最小限のものだけを提供しようとすると、一般的なケースのコードを複数のクライアントが複製することになります。flattenのようなケースでは、多くの人が独自の再帰関数を記述することになります。難しいことではありませんが、それほど珍しいケースではないので、なぜわざわざする必要があるのでしょうか？

lastのような単純なケースでも、読者はイディオムを学ぶ必要があります。単純なメソッドが直接読み取れるのに、なぜ間接的なものを見なければならないのでしょうか？優れたソフトウェアは、まずユーザーを考え、生活を楽にします。人間中心インターフェースはその原則に従います。

人間中心インターフェースは、クライアントがやらなくても済むように、より多くの作業を行います。特に、APIの人間のユーザーは、共通のタスクを容易に行えるようにする必要があります。読み取りと書き込みの両方で。

どちらにも良い議論があります。個人的には人間中心インターフェースのアプローチに傾いていますが、より難しいとは思います。

フォローアップ

これはちょっとした騒ぎを引き起こし、いくつかの興味深く有益な議論につながりました。いつか、それらを理解しやすくするためにリンクの上に簡単な説明を追加するかもしれませんが、それまでは単にリストアップします。この議論は主に、Elliotte Harold氏の人間中心アプローチに対する短いが力強い批判と、James Robertson氏の返答（Robertson氏の投稿のコメントも必ず確認してください）によって引き起こされました。そして、多くの意見が殺到しました | Cees de Groot氏 | Antonio Vieiro氏 | David Hoefler氏 | James Higgs氏 | Peter Williams氏 | Cedric Beust氏 | John D. Mitchell氏 | Stuart Roebuck氏 | Elliotte Harold氏（2） | Jon Tirsen氏 | Hitesh Jasani氏 | Blaine Buxton氏 | Ramnivas Laddad氏 | Anders Noras氏 | James Robertson氏（2） | Kieth Ray氏 | James Robertson氏（3） | Elliotte Harold氏（3） | Charles Miller氏 | Rob Lally氏 | Bernard Notarianni氏 | David Crow氏 | Jim Weirich氏 | Jim Weirich氏（2） | Ian Bicking氏 | Brian Foote氏 | Justin Gehtland氏 | Tom Moertel氏 | Antonio Vieiro氏（2） | Kris Wehner氏 | The Server Side | Ravi Mohan氏 | Danny Lagrouw氏 | Piers Cawley氏 | Peter Williams氏 | Florian Frank氏 | Chris Siebenmann氏。

他にもありますが、すべてを見つけることができず、議論に何か興味深いものを加え、攻撃的なものを避けたものだけを選んでいます。Ruby Array対Java Listの例よりも基本的な原則に過度に焦点を当てる傾向がありましたが、それは自然なことです。議論はいくつかの良い方向に進んでいます。機会があれば、1つか2つの議論を発展させたいと思います。

または、Joey deVilla氏の記事を読むこともできます。- 上記のほとんどの抜粋が含まれています。