軟件設計的哲學（第2版）


	本書深入探討了軟件設計中的核心問題：如何將覆雜的軟件系統分解為可以相對獨立實現的模塊（例如類和方法），從而降低其覆雜性並提高開發效率。本書首先介紹了軟件設計中的基本問題，即覆雜性的本質。其次，討論了有關如何處理軟件設計過程的“哲學”問題，如通用設計的重要性、與《代碼整潔之道》中設計哲學的對比，以及如何將重要的東西和不重要的東西區分開等內容。最後，總結了在軟件設計過程中應遵循的一系列設計原則，以及一系列識別設計問題的警示信號。本書適合軟件工程師、計算機科學專業的學生、教育者、對軟件設計和開發感興趣的自學者和技術管理者閱讀。通過應用本書中的思想，讀者可以最大限度地降低大型軟件系統的覆雜性，從而更快地以更低的成本編寫軟件，並構建更易於維護和增強的系統。編輯推薦 1. 作者專業，內容靠譜：約翰·奧斯特豪特，斯坦福大學計算機科學教授，具有豐富的工業界經驗和學術成就，是Tcl腳本語言的創建者，曾獲多個技術獎項。 2. 系統化解決軟件覆雜性：全面探討軟件設計中的覆雜性管理，提供具體方法以實現覆雜軟件系統的有效模塊化。 3. 實用的設計哲學：與熱銷書的《代碼整潔之道》進行對比，強調通用設計的選擇，教導讀者如何區分軟件設計中的重要事項。 4. 內容全面更新：第二版在前一版基礎上增加了新的設計策略和案例，提供更多實用的設計知識和技巧。



	購買中國簡體書籍請注意： 1. 因裝幀品質及貨運條件未臻完善，中國簡體書可能有出現磨痕、凹痕、折痕等問題，故簡體字館除封面破損、內頁脫落、缺頁等較嚴重的狀態外，其餘所有商品將正常出貨。


	目　　錄第 1章導言 001 1.1 如何使用本書 004 第 2章覆雜性的本質 007 2.1 覆雜性的定義 007 2.2 覆雜性的表現 009 2.3 覆雜性的原因 012 2.4 覆雜性是增量的 014 2.5 結論 015 第3章能工作的代碼是不夠的 017 3.1 戰術性編程 017 3.2 戰略性編程 019 3.3 投資多少？ 020 3.4 初創企業與投資 022 3.5 結論 023 第4章模塊應該深 025 4.1 模塊化設計 025 4.2 接口包含哪些內容？ 027 4.3 抽象 028 4.4 深模塊 029 4.5 淺模塊 031 4.6 類炎 033 4.7 示例：Java和UNIX I/O 033 4.8 結論 035 第5章信息隱藏（和泄漏） 037 5.1 信息隱藏 037 5.2 信息泄漏 039 5.3 時序分解 040 5.4 示例：HTTP服務器 041 5.5 示例：類過多 042 5.6 示例：HTTP參數處理 043 5.7 示例：HTTP響應中的默認值 045 5.8 類內的信息隱藏 046 5.9 過猶不及 047 5.10 結論 047 第6章通用模塊更深 049 6.1 讓類有點通用 049 6.2 示例：為編輯器存儲文本 051 6.3 更通用的API 052 6.4 通用性帶來更好的信息隱藏 054 6.5 要問自己的問題 055 6.6 將專用性向上推（和向下推） 056 6.7 示例：編輯器撤銷機制 057 6.8 消除代碼中的特例 060 6.9 結論 061 第7章不同層，不同抽象 063 7.1 直通方法 064 7.2 接口重覆何時可行？ 066 7.3 裝飾器 067 7.4 接口與實現 069 7.5 直通變量 070 7.6 結論 073 第8章降低覆雜性 075 8.1 示例：編輯器文本類 076 8.2 示例：配置參數 076 8.3 過猶不及 078 8.4 結論 078 第9章合並好，還是分開好？ 079 9.1 如果共享信息，則合並 081 9.2 如果可以簡化接口，則合並 081 9.3 消除重覆，則合並 082 9.4 區分通用代碼和專用代碼 085 9.5 示例：插入光標和選擇區域 086 9.6 示例：單獨的日志類 087 9.7 拆分和連接方法 089 9.8 不同意見：《代碼整潔之道》 092 9.9 結論 093 第 10章避免處理異常 095 10.1 為何異常會增加覆雜性 095 10.2 異常太多 098 10.3 定義錯誤不存在 100 10.4 示例：Windows中的文件刪除 100 10.5 示例：Java的substring方法 101 10.6 異常屏蔽 103 10.7 異常聚合 104 10.8 就讓它崩潰 109 10.9 過猶不及 110 10.10 結論 111 第 11章設計兩次 113 第 12章為什麽要寫注釋？4個借口 117 12.1 好的代碼自己就是文檔 118 12.2 我沒有時間寫注釋 119 12.3 注釋會過時，會產生誤導 120 12.4 我見過的注釋都沒有價值 121 12.5 寫好注釋的好處 121 12.6 不同觀點：注釋就是失敗 122 第 13章注釋應描述代碼中不明顯的內容 125 13.1 選擇約定 126 13.2 不要重覆代碼 127 13.3 低層注釋增加精確度 130 13.4 高層注釋增強直觀性 133 13.5 接口文檔 136 13.6 實現注釋：做什麽和為什麽，而不是怎麽做 144 13.7 跨模塊設計決策 146 13.8 結論 149 13.9 13.5節問題解答 150 第 14章選擇名稱 151 14.1 示例：糟糕的名稱會導致缺陷 151 14.2 塑造形象 153 14.3 名稱應精確 153 14.4 一致地使用名稱 157 14.5 避免多余的詞 158 14.6 不同意見：Go風格指南 159 14.7 結論 161 第 15章先編寫注釋 163 15.1 拖延的注釋是糟糕的注釋 163 15.2 先編寫注釋 164 15.3 注釋是一種設計工具 165 15.4 早期注釋是有趣的注釋 166 15.5 早期注釋是否昂貴？ 167 15.6 結論 168 第 16章修改現有代碼 169 16.1 持續使用戰略性編程 169 16.2 維護注釋：讓注釋靠近代碼 171 16.3 注釋屬於代碼，而非提交日志 172 16.4 維護注釋：避免重覆 173 16.5 維護注釋：檢查差異 175 16.6 更高層次的注釋更容易維護 175 第 17章一致性 177 17.1 一致性的例子 177 17.2 確保一致性 178 17.3 過猶不及 181 17.4 結論 181 第 18章代碼應顯而易見 183 18.1 讓代碼更顯而易見 184 18.2 讓代碼不顯而易見的因素 186 18.3 結論 190 第 19章軟件發展趨勢 191 19.1 面向對象編程和繼承 191 19.2 敏捷開發 193 19.3 單元測試 194 19.4 測試驅動開發 196 19.5 設計模式 197 19.6 取值方法和設值方法 197 19.7 結論 198 第 20章性能設計 199 20.1 如何考慮性能 199 20.2 修改前（後）的度量 202 20.3 圍繞關鍵路徑進行設計 203 20.4 示例：RAMCloud的Buffer類 204 20.5 結論 210 第 21章確定什麽是重要的 211 21.1 如何確定什麽是重要的？ 211 21.2 盡量減少重要的東西 212 21.3 如何強調重要的東西 213 21.4 錯誤 213 21.5 更廣泛的思考 214 第 22章結論 215 設計原則總結 217 警示信號總結 219