関連サイト
本書の関連ページが用意されています。
内容紹介
これまで設計の良くないAPIが数多く生まれてきました。なぜ、そうしたソフトウェアが量産されるのでしょう。エンジニアが良いAPI・悪いAPIについて分かっていない、あるいは、適切なレビューを受けていないからかもしれません。本書では、NetBeansアーキテクトの著者が遭遇してきた様々な誤りを解説し、APIの発展を考慮した設計について詳しく説明します。あまり語られることがなかったAPI設計について、貴重な10年間の経験をベースに幅広くノウハウを披露しています。API設計の技術や知見の水平線を押し広げることができる稀有な一冊です。
◆オブジェクト指向アプリケーションフレームワークには、伝統的なデザインパターンとは異なるスキルが必要
◆クラスをAPIとして扱って、頭痛の種を軽減
◆将来、改善できるようにAPIの発展計画を準備
◎共有ライブラリ、フレームワークの設計に役立つ
◎仮想マシンベースのオブジェクト指向言語に適用できる
書誌情報
- 著者: Jaroslav Tulach, 柴田 芳樹(訳)
- ページ数: 432ページ(PDF版換算)
- 対応フォーマット: EPUB
- 出版社: インプレス
対象読者
中級以上のプログラマー（主にJavaプログラマー）
著者について
Jaroslav Tulach
NetBeansの生みの親で、初期のアーキテクト。NetBeansは当初、Java統合開発環境として開発され、現在はJavaScript・Ruby・PHP・C/C++などにも対応。今も、オープンソースプロジェクトで開発が続けられている。著者は、NetBeansを支える技術の生みの親として、このオープンソースプロジェクトの成功に貢献。現在も、プログラマーの設計スキルを向上させる新たな方法を探究しつつ、このプロジェクトに参加している。
柴田 芳樹
1959年生まれ。九州工業大学情報工学科で情報工学を学び、1984年同大学大学院で情報工学修士課程を修了。以来、様々なソフトウェア開発に従事。ゼロックス社のパロアルト研究所を含め、5年間米国に駐在してソフトウェア開発に携わる。現在はソフトウェア開発、教育、コンサルテーションなどを業務としている。
目次
訳者まえがき
目次
- □API設計は別物
- □この本が対象とする読者
- □この本は、Javaだけに役立つのでしょうか
- □APIの作成を学ぶ
- □この本は、本当にノートなのか
第1部 理論と正当性
第1章 現代的なソフトウェア構築の技芸
- 1.1 合理主義、経験主義、無知
- 1.2 今までのソフトウェアの発展
- 1.3 巨大なビルディングブロック
- 1.4 美しさ、真実、優雅さ
- 1.5 さらなる無知
第2章 APIを作成する動機
- 2.1 分散開発
- 2.2 アプリケーションのモジュール化
- 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の品質検査方法
第4章 絶え間なく変わる標的
- 4.1 最初のバージョンは決して完璧ではない
- 4.2 後方互換性
- 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 どこにでもLookup
- 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.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.3 コンテスト2日目
- 17.4 コンテスト3日目：最後の審判の日
- 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設計方法論
- □発展の準備ができている言語
- □教育の役割
- □共有してください！