軟件框架設計的藝術

第一部分 理論與理由
第1章 軟件開發(fā)的藝術
1.1 理性主義，經(jīng)驗主義以及無緒
1.2 軟件的演變過程
1.3 大型軟件
1.4 漂亮，真理和優(yōu)雅
1.5 更好的無緒
第2章 設計api的動力之源
2.1 分布式開發(fā)
2.2 模塊化應用程序
2.3 交流互通才是一切
2.4 經(jīng)驗主義編程方式
2.5 開發(fā)第一個版本通常比較容易
第3章 評價api好壞的標準
3.1 方法和字段簽名
3.2 文件及其內容
3.3 環(huán)境變量和命令行選項
3.4 文本信息也是api
3.5 協(xié)議
3.6 行為
3.7 國際化支持和信息國際化
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 逐步改善
第二部分 設計實戰(zhàn)
第5章 只公開你要公開的內容
5.1 方法優(yōu)于字段
5.2 工廠方法優(yōu)于構造函數(shù)
5.3 讓所有內容都不可更改
5.4 避免濫用setter方法
5.5 盡可能通過友元的方式來公開功能
5.6 賦予對象創(chuàng)建者更多權利
5.7 避免暴露深層次繼承
第6章 面向接口而非實現(xiàn)進行編程
6.1 移除方法或者字段
6.2 移除或者添加一個類或者接口
6.3 向現(xiàn)有的繼承體系中添加一個接口或者類
6.4 添加方法或者字段
6.5 java中接口和類的區(qū)別
6.6 弱點背后的優(yōu)點
6.7 添加方法的另一種方案
6.8 抽象類有沒有用呢
6.9 要為增加參數(shù)做好準備
6.10 接口vs.類
第7章 模塊化架構
7.1 模塊化設計的類型
7.2 組件定位和交互
7.3 編寫擴展點
7.4 循環(huán)依賴的必要性
7.5 滿城盡是lookup
7.6 lookup的濫用
第8章 設計api時要區(qū)分其目標用戶群
8.1 c和java語言中如何定義api和spi
8.2 api演進不同于spi演進
8.3 java.io.writer這個類從jdk 1.4到jdk 5的演進
8.4 合理分解api
第9章 牢記可測試性
9.1 api設計和測試
9.2 規(guī)范的光環(huán)正在褪去
9.3 好工具讓api設計更簡單
9.4 兼容性測試套件
第10章 與其他api協(xié)作
10.1 謹慎使用第三方api
10.2 只暴露抽象內容
10.3 強化api的一致性
10.4 代理和組合
10.5 避免api的誤用
10.6 不要濫用javabeans那種監(jiān)聽器機制
第11章 api具體運行時的一些內容
11.1 不要冒險
11.2 可靠性與無緒
11.3 同步和死鎖
11.3.1 描述線程模型
11.3.2 java monitors中的陷阱
11.3.3 觸發(fā)死鎖的條件
11.3.4 測試死鎖
11.3.5 對條件競爭進行測試
11.3.6 分析隨機故障
11.3.7 日志的高級用途
11.3.8 使用日志記錄程序控制流程
11.4 循環(huán)調用的問題
11.5 內存管理
第12章 聲明式編程
12.1 讓對象不可變
12.2 不可變的行為
12.3 文檔兼容性
第三部分 日常生活
第13章 極端的意見有害無益
13.1 api必須是漂亮的
13.2 api必須是正確的
13.3 api應該盡量簡單
13.4 api必須是高性能的
13.5 api必須絕對兼容
13.6 api必須是對稱的
第14章 api設計中的矛盾之處
14.1 api設計中的自相矛盾
14.2 背后隱藏的工作
14.3 不要害怕發(fā)布一個穩(wěn)定的api
14.4 降低維護費用
第15章 改進api
15.1 讓有問題的類庫重新煥發(fā)活力
15.2 自覺地升級與無意識地被迫升級
15.3 可選的行為
15.4 相似api的橋接和共存
第16章 團隊協(xié)作
16.1 在提交代碼時進行代碼評審
16.2 說服開發(fā)人員為他們的api提供文檔
16.3 盡職盡責的監(jiān)控者
16.4 接受api的補丁
第17章 利用競賽游戲來提升api設計技巧
17.1 概述
17.2 第一天
17.2.1 非public類帶來的問題
17.2.2 不可變性帶來的問題
17.2.3 遺漏實現(xiàn)的問題
17.2.4 返回結果可能不正確的問題
17.2.5 第一天的解決方案
17.3 第二天
17.3.1 我想修正犯下的錯誤
17.3.2 第二天的解決方案
17.4 第三天：評判日
17.5 也來玩下這個游戲吧
第18章 可擴展visitor模式的案例
18.1 抽象類
18.2 為改進做好準備
18.3 默認的遍歷
18.4 清楚地定義每個版本
18.5 單向改進
18.6 使用接口時的數(shù)據(jù)結構
18.7 針對用戶和開發(fā)商的visitor模式
18.8 三重調度
18.9 visitor模式的圓滿結局
18.10 語法小技巧
第19章 消亡的過程
19.1 明確版本的重要性
19.2 模塊依賴的重要性
19.3 被移除的部分需要永久保留嗎
19.4 分解龐大的api
第20章 未來
20.1 原則性內容
20.2 無緒長存
20.3 api設計方法論
20.4 編程語言的演變
20.5 教育的作用
20.6 共享
參考書目