總結：
好吧，不得不承認，現在的我看架構還早了一點，很多東西看過去毫無感覺，硬着頭皮看完了……哪怕是NetBeans大佬寫的書。大概是代碼寫得不夠多，也沒有涉及這方面工作的經歷，所以感覺對現在的我沒什麼幫助。也罷，先不看架構類的書了，不如看看設計模式，看看源代碼，搞搞框架的應用吧。
前言
只要API有可能被誤用，就一定會有人去誤用這個API。
API就如同恆星，一旦出現，便與我們永恆共存。
編寫API庫需要開發人員放眼未來，看到今後潛在的需求。
API一旦發佈便與我們永恆共存。
第一部分 理論與理由
第1章 軟件開發的藝術
無緒：不需要深入瞭解就使用，像我們現在使用的框架之類的，淺層理解，看電視不需要理解電視機原理，只要會用就行了。
針對性無緒：有些內容需要深入理解，大部分不需要。
第2章 設計API的動力之源
改進現有的系統設計技能，是一種“無緒”利益最大化的有效途徑。
分佈式開發；模塊化應用程序；
並非所有項目的質量都要高得像API。特別是開發的應用程序是給最終用戶使用時，應用部署完之後不會有太大的變化。本書中的各種原則，更適用於系統種那些關鍵的可複用組件。
經驗主義編程方式：很少有人能夠以合理的方式來分析一個新API，沒有人在學習使用一個API的時候，盡力去理解該API背後的設計思路。不需要花費大量時間來思考、學習和理解相應的內容，開發人員秀可以通過哪個是調用API的某個方法來測試會否可以完成目的，如果測試結果正確，開發人員就會很開心，如果測試結果不正確，開發人員就會需調用別的方法，這種方式NetBeans稱其爲經驗主義編程方式（先用一個API做個實驗，如果不成功就試一下別的，經驗第一，然後纔是深入瞭解。不過有時候並不需要深入瞭解）。這就對API的結構提出了要求，API必須是自描述的，即用戶不需要任何文檔就可以正確使用該API。
返回值不能爲空：雖然可以用obj!=null來避免NullPointerException，但是這樣會使代碼凌亂且難以閱讀，建議除非聲明可以爲null否則絕不返回null。
開發第一個版本通常比較容易。問題往往來自於後續版本。要對一個API加以改變並加入一些新功能，但同時還不能影響原來的功能，這是一門精妙的藝術。既要考慮原有API被使用的所有方式，又要保證這些用法適用於新版本，這太困難了。
如果在設計API的時候就考慮到未來改進，而預留出相應的空間，那麼即使出現升級的情況，也不會給其他用戶添加額外的工作。
第3章 評價API好壞的標準
源代碼地址：http://source.apidesign.org
API不僅是類和方法以及javadoc。
方法和字段簽名（反射）；文件及其內容（格式）；環境變量和命令行選項；文件信息也是API；協議（針對文本內容的API）；行爲（組件對外行爲也是一種API）；國際化支持和信息國際化（ResourceBundle）（不允許移除鍵值或重命名鍵值）。
每個協議建立連接時，即使這個協議只是在本地系統上用於內部交互，第一件要做的事就是一個握手協議，明確一些關鍵信息。
API的廣泛定義：不僅是類、方法、函數和簽名這些東西，從簡單的文本信息到那些複雜或者很難控制的組件行爲，都可以算是API。
想要設計一個易於理解的API，對用戶的知識和技巧猜測準確也屬於一種頗具技術含量的方法。
一致性；可見性；簡單的任務應該有簡單的方案；保護投資；
第4章 不斷變化的目標
判斷一個API是否優秀，並不是簡單根據第一版給出判斷的，而是要看多年後改API是否還能存在是否仍舊保持得不錯。
向後兼容。源代碼兼容，不必花費過多的精力去做到絕對的源代碼兼容，因爲非常困難。二進制兼容，不需要重新編譯就能和新版類庫連接。功能兼容，阿米巴變形蟲效應，功能的具體實現可能與其預期差別很大。
無緒定義：集中多個模塊構建一個程序時，無須深入瞭解每一個模塊。
面向用例的重要性。
API設計評審；唯一架構師的方式會受到規模的限制。用例驅動的API設計，API設計的一致性，簡單明瞭的API，少即是多，支持改進。
一個API的生命週期：開發版，穩定版。
開發人員走捷徑使用非正式API或其他手段，會增大軟件熵，代碼變亂，結構框架也變亂。
第二部分 設計實戰
結合設計模式來設計API。
第5章 只公開你要公開的內容
API公開的內容越少越好。
通過編碼技巧提高代碼的可讀性。
經驗告訴我們：對於API設計者來說，其水平越差，他所編寫的API越會公開大量不必要的內容。（往往是由於對用例的理解不足）
一切都以最終用戶爲中心，但要逐步來滿足他們的需求。
方法優於字段。
工廠方法優於構造方法。（可返回子類，不一定每次都創建實例，利於同步控制，利用泛型可支持參數化的返回類型）
讓所有內容都不可更改。
避免濫用setter方法。
儘可能通過友元的方式來公開功能。（同一個package內）不要在API中公開那些外部不應該調用的方法。
避免暴露深層次繼承。
第6章 面向接口而非實現進行編程
接口多繼承可以減少對內存的佔用。
向現有接口中添加方法總是不太容易（兼容難而且代碼會變複雜），final類是可以添加新方法的。
要爲增加新參數做好準備。
第7章 模塊化架構
按照邏輯功能進行功能分解，避免在邏輯模塊間交叉引用產生依賴關係。
模塊化架構將規範與具體實現分離，分別放置在不同的模塊中；可以定義一個模塊專用於放置規範，即其文檔涵蓋實際的接口抽象類等；需要實現規範的開發商可能會提供一個或多個單獨的模塊，用來實現具體的功能；這類設計通常有一個共同點就是：在規範所在的模塊中，至少會有一個小的“入口點”，比如構造函數或者靜態工廠方法，這樣客戶端代碼就可以通過這樣的入口獲取具體的實現內容。
組件定位和交互。
通用的註冊方式。（屬性，XML等）
Spring和Lookup機制。
編寫擴展點。
循環依賴的必要性。
Lookup的濫用。
第8章 設計API時要區分其目標用戶羣
合理分解API
第9章 牢記可測試性
第10章 與其他API協作
謹慎使用第三方API。
如果需要去讀一個API的源代碼，那麼其設計上一定存在問題。
第11章 API具體運行時的一些內容
同步和死鎖。
第12章 聲明式編程
第三部分 日常生活
第13章 極端的意見有害無益
第14章 API設計中的矛盾之處
第15章 改進API
修復亂七八糟的問題：測試用例。結合無緒。
兼容性是一種約束。
本書的大部分章節都將優雅看做一個不重要的內容，認爲向後兼容性比優雅更爲重要，因爲對兼容性的需求是很容易分析出來的。但是API也不能越來越難看，儘量優雅一些。
第16章 團隊協作
在提交代碼時進行代碼評審。
說服開發人員爲他們的API提供文檔。
通常來說，所謂好的建議就是能將產品的開發成本降低，並縮短產品推向市場的時間。
第17章 利用競賽遊戲來提升API設計技巧
正確的判斷來自於經驗，而經驗來自於錯誤的判斷。
第18章 可擴展Visitor模式的案例
第19章 消亡的過程
版本的重要性，模塊的重要性。
分解龐大的API。
第20章 未來
無緒長存。
事物是永遠不會十全十美的，事物是會演化的。
方法論：敏捷API設計。
集成和改進現有代碼或開源代碼的能力可能更實用有效。