相關商品
商品簡介
目次
商品簡介
《軟件框架設計的藝術》幫助你解決API設計方面的問題，共分3個部分，分別指出學習API設計是需要進行科學的訓練的、Java語言在設計方面的理論及設計和維護API時的常見情況，并提供了各種技巧來解決相應的問題。《軟件框架設計的藝術》作者圖拉赫是NetBeans的創始人，也是NetBeans項目最初的架構師。相信在API設計中遇到問題時，《軟件框架設計的藝術》將不可或缺。 《軟件框架設計的藝術》適用于軟件設計人員閱讀。
目次
第一部分 理論與理由
第1章 軟件開發的藝術 4
1.1 理性主義，經驗主義以及無緒 4
1.2 軟件的演變過程 6
1.3 大型軟件 8
1.4 漂亮，真理和優雅 9
1.5 更好的無緒 12
第2章 設計API的動力之源 14
2.1 分布式開發 14
2.2 模塊化應用程序 16
2.3 交流互通才是一切 20
2.4 經驗主義編程方式 22
2.5 開發第一個版本通常比較容易 24
第3章 評價API好壞的標準 26
3.1 方法和字段簽名 26
3.2 文件及其內容 27
3.3 環境變量和命令行選項 29
3.4 文本信息也是API 30
3.5 協議 32
3.6 行為 35
3.7 國際化支持和信息國際化 35
3.8 API的廣泛定義 37
3.9 如何檢查API的質量 37
3.9.1 可理解性 37
3.9.2 一致性 38
3.9.3 可見性 39
3.9.4 簡單的任務應該有簡單的方案 40
3.9.5 保護投資 40
第4章 不斷變化的目標 42
4.1 第一個版本遠非完美 42
4.2 向后兼容 43
4.2.1 源代碼兼容 43
4.2.2 二進制兼容 44
4.2.3 功能兼容——阿米巴變形蟲效應 50
4.3 面向用例的重要性 52
4.4 API設計評審 55
4.5 一個API的生命周期 56
4.6 逐步改善 60
第二部分 設計實戰
第5章 只公開你要公開的內容 67
5.1 方法優于字段 68
5.2 工廠方法優于構造函數 70
5.3 讓所有內容都不可更改 71
5.4 避免濫用setter方法 72
5.5 盡可能通過友元的方式來公開功能 73
5.6 賦予對象創建者更多權利 77
5.7 避免暴露深層次繼承 82
第6章 面向接口而非實現進行編程 85
6.1 移除方法或者字段 87
6.2 移除或者添加一個類或者接口 88
6.3 向現有的繼承體系中添加一個接口或者類 88
6.4 添加方法或者字段 88
6.5 Java中接口和類的區別 90
6.6 弱點背後的優點 91
6.7 添加方法的另一種方案 92
6.8 抽象類有沒有用呢 94
6.9 要為增加參數做好準備 95
6.10 接口VS.類 97
第7章 模塊化架構 98
7.1 模塊化設計的類型 100
7.2 組件定位和交互 103
7.3 編寫擴展點 116
7.4 循環依賴的必要性 117
7.5 滿城盡是Lookup 121
7.6 Lookup的濫用 126
第8章 設計API時要區分其目標用戶群 129
8.1 C和Java語言中如何定義API和SPI 129
8.2 API演進不同于SPI演進 131
8.3 java.io.Writer這個類從JDK 1.4到JDK 5的演進 131
8.4 合理分解API 143
第9章 牢記可測試性 147
9.1 API設計和測試 148
9.2 規範的光環正在褪去 151
9.3 好工具讓API設計更簡單 153
9.4 兼容性測試套件 155
第10章 與其他API協作 158
10.1 謹慎使用第三方API 158
10.2 只暴露抽象內容 162
10.3 強化API的一致性 164
10.4 代理和組合 168
10.5 避免API的誤用 176
10.6 不要濫用JavaBeans那種監聽器機制 180
第11章 API具體運行時的一些內容 184
11.1 不要冒險 186
11.2 可靠性與無緒 189
11.3 同步和死鎖 191
11.3.1 描述線程模型 192
11.3.2 Java Monitors中的陷阱 193
11.3.3 觸發死鎖的條件 196
11.3.4 測試死鎖 201
11.3.5 對條件競爭進行測試 204
11.3.6 分析隨機故障 206
11.3.7 日志的高級用途 208
11.3.8 使用日志記錄程序控制流程 210
11.4 循環調用的問題 215
11.5 內存管理 218
第12章 聲明式編程 223
12.1 讓對象不可變 225
12.2 不可變的行為 229
12.3 文檔兼容性 230
第三部分 日常生活
第13章 極端的意見有害無益 236
13.1 API必須是漂亮的 237
13.2 API必須是正確的 237
13.3 API應該盡量簡單 240
13.4 API必須是高性能的 242
13.5 API必須絕對兼容 242
13.6 API必須是對稱的 245
第14章 API設計中的矛盾之處 247
14.1 API設計中的自相矛盾 248
14.2 背後隱藏的工作 251
14.3 不要害怕發布一個穩定的API 252
14.4 降低維護費用 255
第15章 改進API 258
15.1 讓有問題的類庫重新煥發活力 259
15.2 自覺地升級與無意識地被迫升級 265
15.3 可選的行為 268
15.4 相似API的橋接和共存 274
第16章 團隊協作 286
16.1 在提交代碼時進行代碼評審 286
16.2 說服開發人員為他們的API提供文檔 290
16.3 盡職盡責的監控者 292
16.4 接受API的補丁 297
第17章 利用競賽遊戲來提升API設計技巧 300
17.1 概述 300
17.2 第一天 301
17.2.1 非public類帶來的問題 304
17.2.2 不可變性帶來的問題 304
17.2.3 遺漏實現的問題 308
17.2.4 返回結果可能不正確的問題 309
17.2.5 第一天的解決方案 310
17.3 第二天 313
17.3.1 我想修正犯下的錯誤 316
17.3.2 第二天的解決方案 317
17.4 第三天：評判日 320
17.5 也來玩下這個遊戲吧 327
第18章 可擴展Visitor模式的案例 328
18.1 抽象類 331
18.2 為改進做好準備 333
18.3 默認的遍歷 334
18.4 清楚地定義每個版本 337
18.5 單向改進 339
18.6 使用接口時的數據結構 340
18.7 針對用戶和開發商的Visitor模式 341
18.8 三重調度 343
18.9 Visitor模式的圓滿結局 345
18.10 語法小技巧 346
第19章 消亡的過程 348
19.1 明確版本的重要性 349
19.2 模塊依賴的重要性 349
19.3 被移除的部分需要永久保留嗎 352
19.4 分解龐大的API 352
第20章 未來 356
20.1 原則性內容 357
20.2 無緒長存 358
20.3 API設計方法論 360
20.4 編程語言的演變 361
20.5 教育的作用 363
20.6 共享 365
參考書目 366
第1章 軟件開發的藝術 4
1.1 理性主義，經驗主義以及無緒 4
1.2 軟件的演變過程 6
1.3 大型軟件 8
1.4 漂亮，真理和優雅 9
1.5 更好的無緒 12
第2章 設計API的動力之源 14
2.1 分布式開發 14
2.2 模塊化應用程序 16
2.3 交流互通才是一切 20
2.4 經驗主義編程方式 22
2.5 開發第一個版本通常比較容易 24
第3章 評價API好壞的標準 26
3.1 方法和字段簽名 26
3.2 文件及其內容 27
3.3 環境變量和命令行選項 29
3.4 文本信息也是API 30
3.5 協議 32
3.6 行為 35
3.7 國際化支持和信息國際化 35
3.8 API的廣泛定義 37
3.9 如何檢查API的質量 37
3.9.1 可理解性 37
3.9.2 一致性 38
3.9.3 可見性 39
3.9.4 簡單的任務應該有簡單的方案 40
3.9.5 保護投資 40
第4章 不斷變化的目標 42
4.1 第一個版本遠非完美 42
4.2 向后兼容 43
4.2.1 源代碼兼容 43
4.2.2 二進制兼容 44
4.2.3 功能兼容——阿米巴變形蟲效應 50
4.3 面向用例的重要性 52
4.4 API設計評審 55
4.5 一個API的生命周期 56
4.6 逐步改善 60
第二部分 設計實戰
第5章 只公開你要公開的內容 67
5.1 方法優于字段 68
5.2 工廠方法優于構造函數 70
5.3 讓所有內容都不可更改 71
5.4 避免濫用setter方法 72
5.5 盡可能通過友元的方式來公開功能 73
5.6 賦予對象創建者更多權利 77
5.7 避免暴露深層次繼承 82
第6章 面向接口而非實現進行編程 85
6.1 移除方法或者字段 87
6.2 移除或者添加一個類或者接口 88
6.3 向現有的繼承體系中添加一個接口或者類 88
6.4 添加方法或者字段 88
6.5 Java中接口和類的區別 90
6.6 弱點背後的優點 91
6.7 添加方法的另一種方案 92
6.8 抽象類有沒有用呢 94
6.9 要為增加參數做好準備 95
6.10 接口VS.類 97
第7章 模塊化架構 98
7.1 模塊化設計的類型 100
7.2 組件定位和交互 103
7.3 編寫擴展點 116
7.4 循環依賴的必要性 117
7.5 滿城盡是Lookup 121
7.6 Lookup的濫用 126
第8章 設計API時要區分其目標用戶群 129
8.1 C和Java語言中如何定義API和SPI 129
8.2 API演進不同于SPI演進 131
8.3 java.io.Writer這個類從JDK 1.4到JDK 5的演進 131
8.4 合理分解API 143
第9章 牢記可測試性 147
9.1 API設計和測試 148
9.2 規範的光環正在褪去 151
9.3 好工具讓API設計更簡單 153
9.4 兼容性測試套件 155
第10章 與其他API協作 158
10.1 謹慎使用第三方API 158
10.2 只暴露抽象內容 162
10.3 強化API的一致性 164
10.4 代理和組合 168
10.5 避免API的誤用 176
10.6 不要濫用JavaBeans那種監聽器機制 180
第11章 API具體運行時的一些內容 184
11.1 不要冒險 186
11.2 可靠性與無緒 189
11.3 同步和死鎖 191
11.3.1 描述線程模型 192
11.3.2 Java Monitors中的陷阱 193
11.3.3 觸發死鎖的條件 196
11.3.4 測試死鎖 201
11.3.5 對條件競爭進行測試 204
11.3.6 分析隨機故障 206
11.3.7 日志的高級用途 208
11.3.8 使用日志記錄程序控制流程 210
11.4 循環調用的問題 215
11.5 內存管理 218
第12章 聲明式編程 223
12.1 讓對象不可變 225
12.2 不可變的行為 229
12.3 文檔兼容性 230
第三部分 日常生活
第13章 極端的意見有害無益 236
13.1 API必須是漂亮的 237
13.2 API必須是正確的 237
13.3 API應該盡量簡單 240
13.4 API必須是高性能的 242
13.5 API必須絕對兼容 242
13.6 API必須是對稱的 245
第14章 API設計中的矛盾之處 247
14.1 API設計中的自相矛盾 248
14.2 背後隱藏的工作 251
14.3 不要害怕發布一個穩定的API 252
14.4 降低維護費用 255
第15章 改進API 258
15.1 讓有問題的類庫重新煥發活力 259
15.2 自覺地升級與無意識地被迫升級 265
15.3 可選的行為 268
15.4 相似API的橋接和共存 274
第16章 團隊協作 286
16.1 在提交代碼時進行代碼評審 286
16.2 說服開發人員為他們的API提供文檔 290
16.3 盡職盡責的監控者 292
16.4 接受API的補丁 297
第17章 利用競賽遊戲來提升API設計技巧 300
17.1 概述 300
17.2 第一天 301
17.2.1 非public類帶來的問題 304
17.2.2 不可變性帶來的問題 304
17.2.3 遺漏實現的問題 308
17.2.4 返回結果可能不正確的問題 309
17.2.5 第一天的解決方案 310
17.3 第二天 313
17.3.1 我想修正犯下的錯誤 316
17.3.2 第二天的解決方案 317
17.4 第三天：評判日 320
17.5 也來玩下這個遊戲吧 327
第18章 可擴展Visitor模式的案例 328
18.1 抽象類 331
18.2 為改進做好準備 333
18.3 默認的遍歷 334
18.4 清楚地定義每個版本 337
18.5 單向改進 339
18.6 使用接口時的數據結構 340
18.7 針對用戶和開發商的Visitor模式 341
18.8 三重調度 343
18.9 Visitor模式的圓滿結局 345
18.10 語法小技巧 346
第19章 消亡的過程 348
19.1 明確版本的重要性 349
19.2 模塊依賴的重要性 349
19.3 被移除的部分需要永久保留嗎 352
19.4 分解龐大的API 352
第20章 未來 356
20.1 原則性內容 357
20.2 無緒長存 358
20.3 API設計方法論 360
20.4 編程語言的演變 361
20.5 教育的作用 363
20.6 共享 365
參考書目 366
您曾經瀏覽過的商品
購物須知
大陸出版品因裝訂品質及貨運條件與台灣出版品落差甚大，除封面破損、內頁脫落等較嚴重的狀態，其餘商品將正常出貨。
特別提醒：部分書籍附贈之內容(如音頻mp3或影片dvd等)已無實體光碟提供，需以QR CODE 連結至當地網站註冊“並通過驗證程序”，方可下載使用。
無現貨庫存之簡體書，將向海外調貨：
海外有庫存之書籍，等候約45個工作天;
海外無庫存之書籍，平均作業時間約60個工作天，然不保證確定可調到貨，尚請見諒。
為了保護您的權益，「三民網路書店」提供會員七日商品鑑賞期(收到商品為起始日)。
若要辦理退貨，請在商品鑑賞期內寄回，且商品必須是全新狀態與完整包裝(商品、附件、發票、隨貨贈品等)否則恕不接受退貨。