2014年08月05日

APIデザインの極意

API設計は難しい

"良い"APIを設計するのは難しく、APIの良し悪しを定量的に観測することは難しいとされている。後方互換性や拡張性、不具合の発生率などで曖昧に推し量ることはできるが、これは良い、これは悪い、とはっきり決め付けることは出来ない。そもそもAPIから「これ」と呼べるある側面を切り出すことも難しいと言える。また、APIの設計技法を学べる機会は多くないとしている。物事を感覚として認識することはできても、それを表現し他人に伝え信じてもらう方法を持たない場合が存在する。

API設計を芸術的取り組みにしてはいけない

API設計の過程は創造性を発揮した芸術的な探求とみなすこともできるが、芸術の特性の1つに感情の伝承が出来ないことが挙げられる。複数の芸術家が同じ設計に携わる必要性があるとすれば、芸術家間でのビジョンの共有が必要であり、その方法論、コミュニケーション手法が必要になる。したがって、API設計の過程は(他者とビジョンを共有しにくい)芸術的な取り組みであるべきではなく、科学的な取り組みであるべきである。設計の過程を科学的に捉える方法を学ぶことが、この本を読む目的の1つと言える。

APIは人間向けのインターフェースである

APIはコンピュータ向けではなく寧ろ人間向けのものであるとしている。これは直感に反する指摘かもしれないが、機械が処理しやすいような形式(例えばバイナリ形式)等でコミュニケーションを取るのではなく、適切に記述されたAPIドキュメントを元に開発者同士がコミュニケーションを行うことを考えると、APIは機械を扱う人間同士のコミュニケーション技術に関するものであると考えてもいいだろう。また、後方互換性の話を例に挙げても、APIの設計というのは開発者間の信頼に関する活動であると筆者は指摘している。APIを互換性のある方法、あるいは予想可能な方法で発展させることで信頼を失わないことが常に重要である。

美しさを品質基準として受け入れるべきではない

正しさと美しさが関連付けられることはよくあるが、美しさはしばしば独創性と芸術性をもたらしてしまう。前述の「API設計を芸術的取り組みにしてはいけない」という理由からもそうであるし、また客観的に計測可能にするべきという考え方からも、品質の基準として美しさを取り入れることは好ましくない。これは「美しいものは良いものである」という感覚に反するもので残念ではあるが、使いやすいシステムを作り出すという本来の目的から逸れるべきではない。

発展性を考慮して設計するべき

この本では、APIを設計するときには発展性を考慮するべきとしている。APIをつくった時点では最高に使いやすいものだったとしても、時間が進むにつれて最高ではなくなってしまう。何故なら、APIに対する要求は常に変わっていくものだから。この要求の変化に対して、後方互換性を保ちながら改善していけるということを「発展性」と呼んでいる。

後方互換性がどう失われるか知っておくべき

「APIに変更を加える際には後方互換性を保つ方が良い」という意見には多くの人が同意できると思う。しかしながら、どういう行為によって後方互換性が失われてしまうのかを知らなければAPIを変更できないし、ひいては変更しやすい良いAPIを設計することもできない。文中では、例を上げながら「例えばこういうときにこういう実装にしていてはこのように後方互換性がなくなってしまい、APIの利用者からの信頼を失ってしまう…」といった話が示されている。例えばあるクラスからメソッドを取り除いたときはどうか、またメソッドを追加したときはどうか、また新たにクラスを追加したときはどうか、という具合である。この文脈での「後方互換性」とは、過去のバージョンと未来のバージョンで同じようにコンパイルでき、実行時にもエラーなく動作し、また同じ機能が提供されることを指している。機能の同一性にまで目を向けると、単純にメソッドのシグネチャなどを整えるだけでは後方互換性が守られる保証はないということが分かるだろう。