magazine.gifAPIデザインの極意

日本語版によせて
訳者まえがき

序章:なぜ新たなデザイン本が必要なのか

  • API設計は別物
  • この本が対象とする読者
  • この本は、Javaだけに役立つのでしょうか
  • APIの作成を学ぶ
  • この本は、本当にノートなのか

第1部 理論と正当性
第1章 現代的なソフトウェア構築の技芸

  • 1.1 合理主義、経験主義、無知
  • 1.2 今までのソフトウェアの発展
  • 1.3 巨大なビルディングブロック
  • 1.4 美しさ、真実、優雅さ
  • 1.5 さらなる無知

第2章 APIを作成する動機

  • 2.1 分散開発
  • 2.2 アプリケーションのモジュール化
    • 2.2.1 直線ではないバージョン付け
  • 2.3 すべては、コミュニケーション次第
  • 2.4 経験的プログラミング
  • 2.5 最初のバージョンは常に簡単

第3章 優れたAPIを決定づけるもの

  • 3.1 メソッドとフィールドのシグニチャ
  • 3.2 ファイルとその内容
  • 3.3 環境変数とコマンドラインオプション
  • 3.4 APIとしてのテキストメッセージ
  • 3.5 プロトコル
  • 3.6 振る舞い
  • 3.7 I18NサポートとL10Nメッセージ
  • 3.8 APIの広い定義
  • 3.9 APIの品質検査方法
    • 3.9.1 理解しやすさ
    • 3.9.2 一貫性
    • 3.9.3 発見できること
    • 3.9.4 単純な仕事は簡単でなければならない
    • 3.9.5 投資の保全

第4章 絶え間なく変わる標的

  • 4.1 最初のバージョンは決して完璧ではない
  • 4.2 後方互換性
    • 4.2.1 ソース互換性
    • 4.2.2 バイナリ互換性
    • 4.2.3 昨日互換性-アメーバ効果
  • 4.3 ユースケース指向であることの重要性
  • 4.4 APIレビュー
  • 4.5 APIのライフサイクル
  • 4.6 徐々に改善

第2部 実践的設計
第5章 必要以上に公開しない

  • 5.1 フィールドよりメソッドが優れている
  • 5.2 コンストラクタよりファクトリが優れている
  • 5.3 すべてをfinalにする
  • 5.4 不適切な場所にセッターを用意しない
  • 5.5 フレンドのコードからのみアクセスを許可する
  • 5.6 オブジェクトの作成者に多くの権利を与える
  • 5.7 深い階層を公開しない

第6章 実装ではなく、インタフェースに対してコーディングする

  • 6.1 メソッドやフィールドの削除
  • 6.2 クラスやインタフェースの削除や追加
  • 6.3 既存の階層へのインタフェースやクラスの追加
  • 6.4 メソッドやフィールドの追加
  • 6.5 JavaインタフェースとJavaクラスの比較
  • 6.6 弱さの中に強さがある
  • 6.7 メソッド追加愛好者の天国
  • 6.8 抽象クラスは役立つのか
  • 6.9 パラメータの増加に備える
  • 6.10 インタフェースとクラス

第7章 モジュール方式アーキテクチャの使用

  • 7.1 モジュール方式設計の種類
  • 7.2 コンポーネント間検索とコミュニケーション
  • 7.3 拡張ポインタの作成
  • 7.4 循環依存の必要性
  • 7.5 どこにでもLoopkup
  • 7.6 Lookupの乱用

第8章 クライアント用とプロバイダ用のAPIを分離する

  • 8.1 CとJavaでAPI/SPIを表現する
  • 8.2 APIの発展は、SPIの発展とは異なる
  • 8.3 Java 1.4と1.5の間でのWriterの発展
  • 8.4 適切にAPIを分離する

第9章 テストの容易性に留意する

  • 9.1 APIとテスト
  • 9.2 仕様が姿を消す
  • 9.3 優れたツールは、APIを易しくする
  • 9.4 テスト互換性キット

第10章 他のAPIとの強調

  • 10.1 第三者のAPIの利用に注意する
  • 10.2 抽象化の漏れ
  • 10.3 APIの整合性を強制する
  • 10.4 委譲とコンポジション
  • 10.5 APIの誤用を防止する
  • 10.6 JavaBeansのリスナーパターンを使いすぎない

第11章 APIの実行時の側面

  • 11.1 叙事詩を修正する
  • 11.2 信頼性と無知
  • 11.3 同期とデッドロック
    • 11.3.1 スレッドモデルを文章化する
    • 11.3.2 Javaモニタの落とし穴
    • 11.3.3 デッドロックの条件
    • 11.3.4 デッドロックテスト
    • 11.3.5 競合状態をテストする
    • 11.3.6 ランダムな失敗を解析する
    • 11.3.7 高度なロギングの利用方法
    • 11.3.8 ロギングを使用する実行フロー制御
  • 11.4 リエントラント呼び出しに対して準備する
  • 11.5 メモリ管理

第12章 宣言型プログラミング

  • 12.1 オブジェクトを不変にする
  • 12.2 不変な振る舞い
  • 12.3 ファイルの互換性

第3部 日々の生活
第13章 有害で極端な助言

  • 13.1 APIは、美しくなければならない
  • 13.2 APIは、正しくなければならない
  • 13.3 APIは、単純でなければならない
  • 13.4 APIは、優れた性能でなければならない
  • 13.5 APIは、100パーセント互換でなければならない
  • 13.6 APIは、対照的である必要がある

第14章 API設計のパラドックス

  • 14.1 API二重思考
  • 14.2 目につかない仕事
  • 14.3 安定APIを約束する恐怖を克服する
  • 14.4 保守費用を最小限にする

第15章 API宇宙の発展

  • 15.1 壊れたライブラリを蘇生する
  • 15.2 意識的なアップグレードと無意識なアップグレード
  • 15.3 代わりの振る舞い
  • 15.4 類似APIの橋渡しと共存

第16章 チームワーク

  • 16.1 コードをコミットする前にレビューを行う
  • 16.2 開発者にAPIを文書化することを納得させる
  • 16.3 ビッグブラザーは、決して寝ない
  • 16.4 APIのパッチを受け入れる

第17章 ゲームでAPI設計スキルを向上させる

  • 17.1 API設計フェストの概要
  • 17.2 コンテスト1日目
    • 17.2.1 publicでないAPIクラスの問題
    • 17.2.2 不変性問題
    • 17.2.3 欠けている実装の問題
    • 17.2.4 誤った結果かもしれない問題
    • 17.2.5 1日目の解答
  • 17.3 コンテスト2日目
    • 17.3.1 自分の間違いを修正したいという問題
    • 17.3.2 2日目の解答
  • 17.4 コンテスト3日目:最後の審判の日
    • 17.4.1 結論
  • 17.5 みなさんも、やってみましょう!

第18章 拡張可能なビジターパターンのケーススタディ

  • 18.1 抽象クラス
  • 18.2 発展への準備をする
  • 18.3 デフォルトの走査
  • 18.4 あるバージョンのクリーンな定義
  • 18.5 非単調な発展
  • 18.6 インタフェースを用いるデータ構造
  • 18.7 クライアントビジターとプロバイダビジター
  • 18.8 トリプルディスパッチ
  • 18.9 ビジターのハッピーエンド
  • 18.10 シンタックスシュガー

第19章 終焉の手続き

  • 19.1 仕様バージョンの重要性
  • 19.2 モジュール依存性の重要性
  • 19.3 除去された部分は、永久に存在するべきか
  • 19.4 一枚岩のAPIを分割する

終章:将来

  • プリンキピア・インフォマティカ
  • これからは、無知の時代です
  • API設計方法論
  • 発展の準備ができている言語
  • 教育の役割
  • 共有してください!

参考文献索引