APIデザインの極意 Java/NetBeansアーキテクト探求ノート
APIデザインの極意 Java/NetBeansアーキテクト探究ノート
インプレス
著者：Jaroslav Tulach
訳者：柴田芳樹
日本語版によせて
訳者まえがき
目次
序章：なぜ新たなデザイン本が必要なのか
API設計は別物
この本が対象とする読者
この本は、Javaだけに役立つのでしょうか
A PIの作成を学ぶ
この本は、本当にノートなのか
第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設計方法論
発展の準備ができている言語
教育の役割
共有してください！
参考文献
索引