軟件框架設(shè)計(jì)的藝術(shù)

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