53.正しい使い方を簡単に、誤った使い方を困難に

インタフェースの決定について。Javaなインタフェースより、もっと広義でのインタフェースになりますね。どう使われるかを定義するもの。GUIも含めて、最適なインタフェースと言うのは難しいものです。
例えばPCの電源ボタン。押せば電源が付く。昔のPCはもう一度押したら素直に電源が切れました。正常なシャットダウンを行わずにです。これは電源のON/OFFの目的は満たしていますが、PCとしては誤った使い方が簡単に出来てしまう例です。こういうことをしているとOSが立ち上がらなくなったりもします。最近はもう一度押すとシャットダウンしたりスリープしたりしますね。挙動も設定で変えられます。こういうのが実際に使われる例を見て対応した例になるのでしょうか。

エッセイの中でもインタフェースについては自分で使用する事が推奨されています。いわゆる「ドッグフード」ってやつですね。
実際に自分が使ってみるとわかる事は非常に多いです。コーディング、さらにJavaな話になりますが、メソッド名が気に食わないとかすぐにわかります。パラメータの数の多さに辟易できます。同じ型のパラメータが複数あることの害が理解できます。書いた瞬間は使い方を覚えていても、暫くするとそれが何だったかわからなくなります。自分で自分が書いたコードの中身を見る必要が出てきます。そしてそのインタフェースを作った人に不快感を覚えます。それは自分なわけです。他人を嫌な気分にさせなくて良かったと喜ぶ場面です。
適切なインタフェースには冗長な説明が不要です。たいていの場合、行コメントなんて要らなくなります。ドキュメントコメントも最小限ですみますし、IDEを通してドキュメントコメントを読まなくてもコードを追うだけで意味がわかります。適切なインタフェースは違和感無くコードに溶け込みます。メソッド名と与えられるパラメータの型だけで意味が通じるのが良いインタフェースだと思っています。

自分すら使い辛いものは、他人にとっては不可解な物体になりかねません。いくら便利なものであっても、使い辛ければ使われません。使い方がわかりやすい事は非常に重要だと思います。自分にとって使いやすいものが他人にも使いやすいとは限りませんが、少なくともその可能性は高いと思います。

要するに「説明は不要なのが望ましい」となるでしょうか。どれだけ短くても、読む必要のある説明が有るのと無いのでは使い勝手に雲泥の差があります。説明を読まずに意図が理解出来、正しく使えるならばそれに越した事はありません。作る側として意識しておきたいところです。