APIを作成する動機
![](https://thinkit.co.jp/sites/default/files/styles/main_image_730x/public/main_images/5234_main_3_8.jpg?itok=qJL_WzfS)
APIデザインの極意 Java/NetBeansアーキテクト探究ノート
NetBeans開発プロジェクト10年超の蓄積!API設計の経験や考察をまとめた一冊![Amazon詳細ページへ](/sites/default/files/articles/assocbutt_or_detail._V371070159_.png)
この記事は、書籍『APIデザインの極意 Java/NetBeansアーキテクト探究ノート』の内容を、Think IT向けに特別公開しているものです。
APIを設計することは、容易ではなく、費用がかからないわけでもありません。APIの作成を試みることは、全くAPIを持たない製品をリリースするよりも確かに多くの労力が必要です。それでも、「無知」という状況においてこの本が伝えたいことは、適切なAPIであれば、システムに対する理解を最小限にしながら、優れたシステムを設計できるということです。システムの個々の要素のAPIが適切に設計され、それらを使用することで、システムを設計するために使用するソフトウェアエンジニアリング方法を改善することができます。システムエンジニアリングのスキルを向上させることは、無知の恩恵を最大にする方法です。
分散開発
無知モデルは、世界中のソフトウェアプロジェクトから集められた大きなビルディングブロックを使用することに基づいています。できるだけ再利用することと、すべてを社内だけで書かないことで、製品開発チームは最も重要な差別化機能に集中することができます。つまり、アプリケーションのロジックに集中できます。基盤となる部分を作成するために時間を費やす必要はもはやありません。代わりに、他の人達が作成したフレームワークや有用なライブラリを再利用することができます。今は、誰も社内でSQLデータベースサーバを作成したりしません。人々は、定評のある商用ベンダーが提供するデータベースサーバか、新たに登場しているオープンソースのデータベースを再利用します。内部で利用するSQLデータベースサーバの実装に煩わされることは、資金を無駄に浪費していると見なされるでしょう。多くのソフトウェア技術の領域で同じことが起きています。ウェブとアプリケーションサーバ、言語とそのライブラリ、統合開発環境(IDE)、リッチ・クライアント・アプリケーションのフレームワークは、すべて確立したビルディングブロックとなってきています。すでにパッケージとなっているディナーや事前に組み立てられたアパートの棟のように、在庫から取り出して、組み立てて、それから必要に応じて仕上げを施すことができます。このやり方は、ソフトウェアシステムを生み出すために必要な開発期間を大幅に短縮させます。
アプリケーション全体を組み立てる際には、個々のビルディングブロックを糊付けする必要があります。それらのブロックは、何らかの方法でお互いに話をする必要があります。たいていは、明確に定義されたAPIを通して話をします。各コンポーネントのAPIは、みなさんの無知を増加させるための最初の一歩です。各コンポーネントの内部すべてを理解して知る必要はありません。普通は、コンポーネントのドキュメンテーションを読んで、アプリケーション内でうまくそのAPIを使用するだけで十分です。APIは、ビルディングブロックとしての機能を提供しているコンポーネントの詳細を理解する必要性を最小限にしてくれます。
抽象概念が漏れている!
APIは、各コンポーネントの機能と内部実装に関する抽象概念と見なすことができます。たいていは、その抽象概念を理解するだけで十分ですが、場合によっては、APIを通してコンポーネントの内部が「漏れて」しまっています。例として、ファイルシステムの抽象概念を見てみましょう。通常のファイルシステムは、ツリーに似た階層構造でできているファイルとディレクトリの集合です。ファイルが分かっていれば、その内容を問い合わせることができますし、ディレクトリであれば、その下のファイルの一覧を問い合わせることができます。ファイルの内容は、ストリームとして表現されています。これは、今日のほとんどすべてのオペレーティングシステムで使用されている周知の抽象的概念です。それにより、普通のアプリケーションプログラマは、ファイルシステムの実際のストレージや種別を扱っている詳細から隔離されています。ファイルを読み込むためには、それがハードディスク、CD-ROM、フラッシュディスク、あるいは、ネットワークなどのどこから行われるかを知ることは重要ではありません。ファイルシステムの抽象概念は、どれであっても常に同じです。
しかし、時には、これらの抽象概念の背後にある実際の実装が漏れてしまっています。たとえば、フラッシュドライブを扱う際には、ユーザがディスクを抜いてしまうと読み込んでいる最中にディスクが消える可能性があります。あるいは、ネットワークの場合には、ネットワークが遅かったり、通信品質が悪かったりすると、大きな遅延になることがあります。これらの場合には、抽象概念を理解するだけでなく、少なくとも部分的には、背後にある実装も理解する必要があります。
一方、選択的無知の観点からは、これは完全に受け入れられます。一般的なAPIは、基本的な抽象概念にすぎず、遅延や、取り除かれたディスクからファイルを読む際のクラッシュを気にしなければ、APIとしての機能を果たします。気にするのであれば、状況を把握して対処するためのもっと高度な方法があります。したがって、ファイルシステムAPIは、私達が無知であることに役立ちますし、必要な場合には知識を増やすことを妨げたりしません。これは、きちんと機能を提供するAPIに当てはまるべきことです。