# 目次
# はじめに
以下の記事は，オライリージャパン社から出版された
『プログラマが知るべき97のこと』
の中から1つのエッセイを選び，
そのエッセイを，クリエイティブコモンズ3.0の条件の元で転載したものです．
Creative Commons ― 表示 3.0 アメリカ合衆国 ― CC BY 3.0
本書の内容は，オープンソースモデルに従い，
ほぼ無制限で利用が可能です．
クリエイティブ・コモンズ表示3.0の条件下で，
自由に使用することができるのです．
つまり，どのエッセイも，
著者の名前を明記すれば，自由に転載，改変が可能であるということです．
ーー"はじめに"から抜粋 pXII
もし，他のエッセイを読みたい場合には，
記事末のリンクを辿るか，
以下のリンク先のTwitterアカウントのつぶやきからお探し下さい．
Twitter Account: 97 Things Bot
また，元の英文によるエッセイを読みたい方は，
こちらを参照して下さい．
Contributions Appearing in the Book - Programmer 97-things
19. 誰にとっての利便性か グレゴー・ホーペ (Gregor Hohpe)：『プログラマが知るべき97のこと』
優れたAPIの設計の重要性，そして難しさについては，
これまで多くのことが語られてきました．
最初から適切なAPIを作ることは難しく，
しかし後からAPIに変更を加えることはもっと難しい
（まるで子育てのような難しさ）
と言っても良いでしょう．
経験を積んだプログラマならほぼ皆知っていることでしょうが，
優れたAPIとは，
まず抽象度がどこをとっても一様であり，
その上で整合性，対称性を備えているものです．
優れたAPIはプログラミング言語のボキャブラリーを充実させ，
言語に豊かな表現力を与えるものでもあります．
しかし，そうした原則を十分に意識していたとしても，
適切なAPIができるとは限りません．
甘い物は体に必要だが，食べ過ぎると健康によくない，
というのと同様に，
原則にとらわれすぎると，かえって悪い結果を招くことがあるのです．
こう書いただけだと曖昧で良く分からないと思いますので，
具体例を上げることにしましょう．
以下の３つは，どれもAPIを設計する人が
実際の作業時に言いそうなことです．
そして，
どの意見も「その方が利便性が高い」という理由で正当化されやすいのです．
・ほとんど同じ目的の呼び出しコードがクラスAにすでに存在するのに，
クラスBに新たに呼び出しコードを持たせる必要はないのではないか．
・目的がほぼ同じメソッドがすでに存在するのであれば，
わざわざ新たなメソッドを作る必要はないのではないか．
switch文を追加するぐらいでいいのではないか
・二番目の文字列パラメータが".txt"になっていれば，
自動的に第一パラメータをファイル名であるとみなして構わない．
従って，メソッドを二つ作る必要はない．
簡単な話だ．
どれも善意から出た意見なのは確かです．
しかし，こういう意見に従ってAPIを作ると困ったことがおきます．
それは，「APIを使用したコードが非常に読みにくくなってしまう」．
ということです．
たとえば，メソッド呼び出しのコードがこんなふうになります．
parser.processNodes(text,false);
このコードが何を意味するのか？
APIの内部の実装を知らない人にはおそらくわからないはずです．
ドキュメントを調べて何とかわかればまだ良い方でしょう．
このメソッドは，確かに利便性を考えて設計されているのですが，
それはメソッドを
「実装する側にとっての利便性」
であり，決して
「呼び出す側にとっての利便性」
ではないのです．
「することはほとんど同じなのに，
二種類の呼び出しを使うのは不便ではないか」
というのは，
要するに呼び出す側にとって不便というのではなく，
コードを書く自分が，
内容のほとんど同じメソッドを二つ書くのが
「面倒」という意味なのです．
冗長で，不整合で，美しくないものを作りたくない，
という意図は基本的には間違っていません．
しかし，落ち着いて，より深く考えるならば，
それらの対偶にあるのは，
効率的，整合性，美しさです．
必ずしも，
「利便性」
ではありません．
APIを作るというのは，
複雑な処理を隠蔽するということです．
これは正確には，APIを作る側が，
複雑な処理を隠すために
面倒な作業を引き受けなくてはならないということです．
そうしなくては優れたAPIなどできません．
作る側にとってみれば，
考え抜かれたメソッドをいくつも書くよりも，
大きなメソッドを一つ書く方が「便利」です．
しかし，それは使う側にとって
本当に「便利」でしょうか？
より良いAPIを作るには，
APIを一つの言語だと考えるといいと思います．
APIを表現力豊かな言語にするにはどうすればいいかを考えるのです．
基本的な言語なら，
「意味のある問いを立て，それに答える」
ということができれば十分ですが，
APIはさらに上のレイヤーの言語にするのです．
つまりAPIでは，一つの問いに対応する動詞，
つまりメソッドが必ず一つとは限らない，ということです．
ボキャブラリーに多様性を持たせれば，
微妙な意味の違いが容易に表現できます．
例えば，walk(true)というようなコードを書かされるよりは，
単にrunと書ける方が間違いなく使いやすいでしょう．
walk(歩く）とrun(走る)は本質的には同じ動作で，
ただスピードだけが違うとみなすこともできるのですが，
言葉が二つある方が使う側にとっては便利なのです．
このように，一つ一つ考え抜かれ，
整合性と豊富なボキャブラリーを兼ね備えたAPIを
上のレイヤーとして追加すれば，
言語の表現力が高まり，
コードも読みやすく，
理解しやすくなります．
APIを利用して，
プログラマが自ら新たなボキャブラリーを作れるようになっていると
さらにいいでしょう．
APIを作った人間がまったく予期していなかったような使い方を，
プログラマが自由に考えられるということです．
それができれば，APIを使う側にとっては非常に便利です．
APIの開発をしていて，
複数の要素を一つのメソッドに詰め込みたい衝動に駆られたら，
是非，思い出してください．
例えば，英語には，
「部屋を片付けて，静かに宿題をやりなさい」
（Make up your room, be quiet and do your homework)
ということを一語で伝えられるような単語はないのです．
たとえ同じことを何度も繰り返し言っていて，
一語にまとめられれば，便利だと思っても，
それはしない方が懸命なのです．
■著者データ
[グレゴー・ホーペ (Gregor Hohpe)]
Googleのソフトウェアエンジニアであり，
非同期メッセージングやSOA（Service Oriented Architecture)
に関する考えが広く知られている．
彼の考え方は，好著，
『Enterprise Integration Patterns』
Addison-Wesley Professional
売り上げランキング: 32232
をはじめ，数々の文献でも知ることができる．
詳しくはサイトを参照のこと．
Home - Enterprise Integration Patterns
関連記事
1．分別のある行動 Seb Rose：『プログラマが知るべき97のこと』 - MY ENIGMA
2．関数プログラミングを学ぶことの重要性 Edward Garson：『プログラマが知るべき97のこと』 - MY ENIGMA
3．ユーザが何をするかを観察する (あなたはユーザではない) Giles Colborne：『プログラマが知るべき97のこと』 - MY ENIGMA
4．コーディング規約を自動化する Filip van Laenen：『プログラマが知るべき97のこと』 - MY ENIGMA
5．美はシンプルさに宿る Jorn Olmheim：『プログラマが知るべき97のこと』 - MY ENIGMA
6．リファクタリングの際に注意すべきこと Rajith Attapattu：『プログラマが知るべき97のこと』 - MY ENIGMA
7．共有は慎重に Udi Dahan：『プログラマが知るべき97のこと』 - MY ENIGMA
8. ボーイスカウト・ルール Robert C. Martin：『プログラマが知るべき97のこと』 - MY ENIGMA
9. 他人よりまず自分を疑う Allan Kelly：『プログラマが知るべき97のこと』 - MY ENIGMA
10. ツールの選択は慎重に Giovanni Asproni：『プログラマが知るべき97のこと』 - MY ENIGMA
11. ドメインの言葉を使ったコード Dan North：『プログラマが知るべき97のこと』 - MY ENIGMA
12. コードは設計である Ryan Brush：『プログラマが知るべき97のこと』 - MY ENIGMA
13. コードレイアウトの重要性 Steve Freeman：『プログラマが知るべき97のこと』 - MY ENIGMA
14. コードレビュー Mattias Karlsson：『プログラマが知るべき97のこと』 - MY ENIGMA
13. コードレイアウトの重要性 Steve Freeman：『プログラマが知るべき97のこと』 - MY ENIGMA
14. コードレビュー Mattias Karlsson：『プログラマが知るべき97のこと』 - MY ENIGMA
15. コードの論理的検証 Yechiel Kimchi：『プログラマが知るべき97のこと』 - MY ENIGMA
16. コメントについてのコメント Cal Evans：『プログラマが知るべき97のこと』 - MY ENIGMA
17. コードに書けないことのみをコメントにする Kevlin Henney：『プログラマが知るべき97のこと』 - MY ENIGMA
MyEnigma Supporters
もしこの記事が参考になり、
ブログをサポートしたいと思われた方は、
こちらからよろしくお願いします。
