APIを作成する動機
典型的なアプリケーションは、1つか2つのライブラリから構成されることはありません。今日開発されているアプリケーションは、世界中にある多くのオープンソースライブラリを使用しています。オープンソースとして提供されているものには、Unixのようなカーネル、基本Cライブラリ、コマンドラインのツールなどから始まり、ウェブサーバやウェブブラウザ、Ant、Tomcat、JUnit、JavaCCなどの多くのJavaツールへと広がっています。実際、これらのライブラリは、それぞれ独自のAPIを持っています。結果として、そのようなソフトウェアを作成している人は誰もが、認識しているかどうかに関係なく、API設計ビジネスに従事していることになります。
このような組み立て方法というのは、Linuxディストリビューションの一般的な運用モデルです。様々な人々により、Linuxディストリビューションのソフトウェアは書かれています。そして、集められて、パッケージ化され、全部が統合されます。たいていディストリビューション・ベンダが、中心となる管理ユーティリティを作成し、すべての選択されたコンポーネントが一緒にきちんと機能することを確認するための何らかの品質保証を行います。このモデルは、ほとんどベンダとユーザに対してうまく機能しているようですし、ディストリビューションを作成するコストを下げています。このモデルの成功している例として、Mac OS Xは、Apple社による数多くのアドオンを持つFreeBSD Unixディストリビューションであることを指摘しておきます。
分散開発は、独自の特質を持っています。最も明らかな特質は、アプリケーション全体のソースコードは、開発者の完全な管理下にはないことです。世界中に分散しています。このような方法でソフトウェアを構築することは、社内のソースリポジトリ内のソースコードからアプリケーション全体を構築することとは明らかに異なっています。
このモデルでは、製品全体のスケジュールを完全に統制できないことを認識する必要があります。ソースコードだけでなく、開発者も世界中に分散しており、各人のスケジュールで働いており、完全に統制することはできません。しかし、それほど異常でもなく、危険でもありません。50人以上のチームでプロジェクトをスケジュールしようとしたことがあれば、完全に統制するという考えは、せいぜい慰め程度の幻想にすぎないということが分かっています。常に、機能を落とすか、古いバージョンをリリースするかの準備ができていなければなりません。同じモデルが、分散開発でも当てはまります。誰もが持つ基本的権利は、より新しいバージョンのライブラリを使用するか、古いバージョンのライブラリを使用するかについて自由であることです。
実際、オープンソースだけが、優れたAPIへの増大する需要の牽引力ではありません。商用ベンダも多くの共有ライブラリやフレームワークを作り出しています。それらの多くは、SQLなどの既存の標準を実装したり、独自のAPIを提供したりしています。しかし、寛大なライセンス形態を持つオープンソース活動は、再利用可能なビルディングブロックとしてのコンポーネントの主要供給元になってきました。オープンソースによる解決は、利用料金なしで使用するエンドユーザにはよく知られています。しかし、ライセンス制約がないため、開発者にとっても重要となっています。既存のコンポーネントを選んで、自分のアプリケーションの一部として使用することは簡単です。ほとんどの場合、遅かれ早かれそのように利用されます。それは、すべてのオープンソースのコンポーネントは、いずれ、APIを必要とするようになることを意味しています。これらのコンポーネントは、様々な開発者により開発され、独自のプロジェクトを始めた大学生、独自のおもちゃプロジェクトを開発している経験の長い開発者、オープンソース形式の開発をビジネスチャンスと見なしている会社で働いて給与をもらっている開発者などです。これらの人々は、様々なスキルを持ち、様々な働き方をしています。とにかく、優れたAPIを作り出すことは重要です。なぜなら、APIは、ライブラリの無知な利用のための最初のステップだからです。多くのライブラリやフレームワークを持てば持つほど、それらは良くなっていきます。しかし、無知な利用が成功するためには、APIがライブラリの本質的な真意をきちんと反映していることがいつも重要です。それが、API設計が重要である理由であり、この本を執筆した重要な動機の1つです。
| この記事のもとになった書籍 | |
|---|---|
Jaroslav Tulach 著/柴田 芳樹 訳 |
APIデザインの極意 Java/NetBeansアーキテクト探究ノートなぜ、設計の良くないAPIを持つソフトウェアが量産されるのでしょう。エンジニアが良いAPI・悪いAPIについて分かっていない、あるいは、適切なレビューを受けていないからかもしれません。本書では、NetBeansアーキテクトの著者が遭遇してきた様々な誤りを解説し、APIの発展を考慮した設計について詳しく説明。あまり語られることがなかったAPI設計について、貴重な10年間の経験をベースに幅広くノウハウを披露。API設計の技術や知見の水平線を押し広げることができる稀有な一冊です。
|
