「APIデザインの極意」-APIを作成する動機

「APIデザインの極意」 の 第2章 APIを作成する動機 で気になった部分の抜粋

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

分散開発

• アプリ全体を組み立てる際には個々のビルディングブロックを糊付けする必要があり、それらのブロックはお互いに会話をする必要がある。
• たいていは、明確に定義されたAPIを通して話しをする。
• 各コンポーネントのAPIは、みんなの無知（ ※選択的無知）を増加させるための最初の一歩である。
• APIは機能を提供しているコンポーネントの詳細を理解する必要性を最小限にしてくれる。
• APIは各コンポーネントの機能と内部実装に関する抽象概念とみなすことができる
• 無知な利用が成功するためには、 APIがライブラリの本質的な真意をきちんと反映していることが重要

（※選択的無知 ・・・ 何を深く知り、何を深く知る必要がないかを積極的に選択すること）

アプリケーションのモジュール化

• コンポーネントには名前が必要
• 名前は一意でシステム内でコンポーネントを特定できて、そして、 説明的でなければならない
• コンポーネントが名前を持つ必要があると期待することは自然な流れに思える。しかし、この点を注意深く見てみると、 これらの名前はコンピュータよりも人にとって重要であると分かる。
• コンポーネントがたいていは人が理解できる名前を持っているという事実は、名前が主に対象としているのは人間という証です。
• モジュール方式のシステム内の個々のコンポーネントは必要とするほかのすべてのコンポーネントに関する情報を保持ししている。
• モジュール方式のシステムではほかのコンポーネントへの依存は、 依存先コンポーネントの識別名と必要な最低バージョンを示すことで表現することができる。

すべては、コミュニケーション次第

• アプリケーションは無知の概念に基づいており、アプリケーションの最終組み立てを行う人を限界まで無知に近づけようとする。
• 結果として理想的なアプリケーションは、モジュール方式のアーキテクチャに基づいている。
• APIがうまく設計されていなければ、使用する側はそのAPIの作者の意図を正しく理解できずに誤用する。
• APIが信頼できるものであるためには、 誤った利用を防ぐ必要があり 、また、 発展する準備ができていなけれなばらない。
• 最初に作成された時に完璧であるAPIはほとんどありません。
• APIの将来的な改善をおこなうための重要な条件は 分離です。

経験的プログラミング

• APIは自己文書化されている必要がある。
• 言い換えると ドキュメント無しで利用可能である 必要があります
• APIは解決すべき課題へとAPIのユーザを自然に導かなければならない

---

関連エントリ