學習設計模式，選定了三本書：
1. 設計模式精解 [美]Alan Shalloway & James R. Trott著
很基礎的書，沒有全面介紹23種模式，但是比較好懂，已經看完了。
2.設計模式-可復用面向對象軟件的基礎 GOF
公認的設計模式經典之作，不是很好懂，考驗考驗耐心吧，早些時候看了一半，就沒看了，感覺收獲很少，看完了第一本書后，現有撿起這本來從頭看起，應該會有不少收獲。
3.設計模式精解-GOF23種設計模式解析 一牛人寫的手稿
這個是某牛人深刻理解和實際應用GOF那一幫理論后，寫的一個手稿，感覺很不錯，已經看完了，現又看準備一遍。
這兒準備記錄些書中比較經典的文字，以及自己的些些理解。歡迎指正，共同探討。
1、懂了設計模式，你就懂了面向對象分析和設計（OOA/D）的精要。反之好像也可能成立。道可道，非常道。道不遠人，設計模式亦然如此。
【排第一的當然是這一句了！道可道，非常道，順便查了下這句話的出處老子《道德經》：“道可道也，非恒道也。名可名也，非恒名也。無名，萬物之始也；有名，萬物之母也。故恒無欲也，以觀其眇；恒有欲也，以觀其所徼。兩者同出，異名同謂。玄之又玄，眾眇之門。” 簡單理解就是，“道”是可以意會的，但不可以言傳。哈哈，感覺設計模式也是這樣，往往只能由某個例子去通過“模式”的方法去解決某個問題，來說明模式的存在，在設計模式精解（第一本書里）最后幾章，感覺作者是在拿著問題用一個一個的模式去套，違背了它的本意。正如下句所說：】
2、設計模式體現的是一種思想，而思想則是指導行為的一切，理解和掌握了設計模式，并不是說記住了 23 種（或更多）設計場景和解決策略（實際上這也是很重要的一筆財富），實際接受的是一種思想的熏陶和洗禮，等這種思想融入到了你的思想中后，你就會不自覺地使用這種思想去進行你的設計和開，這一切才是最重要的。
3、設計模式之于面向對象系統的設計和開發的作用就有如數據結構之于面向過程開發的作用一般，其重要性和必要性自然不需要我贅述。
4、Scott Mayer 在其巨著《Effective C++》就曾經說過：C++老手和C++新手的區別就是前者手背上有很多傷疤。是的在軟件開發和設計的過程中，失敗、錯誤是最好的老師，當然在系統開發中，失敗和錯誤則是噩夢的開端和結束，因為你很難有改正錯誤的機會。因此，盡量讓自己多幾道疤痕是對的。
5、面向對象系統的分析和設計實際上追求的就是兩點，一是高內聚(Cohesion),而是低耦合（Coupling）。這也是我們軟件設計所準求的，因此無論是 OO 中的封裝、繼承、多態，還是我們的設計模式的原則和實例都是在為了這兩個目標努力著、貢獻著。
6、寫這些文章，本身沒有任何功利的雜念，只是一個原生態的沖動，反而很輕松的完成了。有心栽花未必發，無心之事可成功，世間的事情可能在很多的時候恰恰就是那樣了。【作者的心態很令人欣賞....】
（1到6是擇自設計模式手稿（第三本書））
7、設計模式是針對特定場景下的特定問題的可重復、可表達的解決方案。它不限于面向對象。不限于設計階段，甚至不限于軟件開發領域。
8、 從概念層次來看，一個對象是一系列的責任。 從規范層次來看，一個對象是一系列可以被其他對象或者該對象自己調用的方法。從實現層次來看，一個對象是一些代碼和數據。
9、一個分析的缺陷：過早對細節投入太多的關心。分析者可能共同存在一個問題：在開發過程中過早的投入了細節分析。這也很自然，因為細節上的問題總是很具體很容易的。細節上的解決方案通常很明顯，但這未必是一個最好的起點。應該盡可能晚地投入細節中去。
10、 設計模式源于建筑學和人類學。【延伸閱讀著名建筑師Christopher Alexander的名著：The Timeless Way of Building，有中譯本，已經看過，譯本形如散文，很有意思。】
11、最主要的一點就是封裝變化的概念，這是許多設計模式的主題。發現并封裝變化點。
12、換句話說，如果變化點是問題領域中的特定的具體情況，共同點就定義了問題領域中將具體情況捆綁在在一起的概念。共同的概念將由抽象類來表現。而變化點分析發現的變化點將由具體類（使用特定實現的派生自抽象類的類）來實現。
13、在創建設計以處理變化的過程中，應該遵循兩條基本策略：
·發現并封裝變化點。
·優先使用對象組合，而不是類繼承。
過去，開發這常常依靠擴展繼承來為這些變化點定位。但是，第二條策略告訴我們，應該盡可能嘗試使用對象組合。其意圖是可以在獨立的類中包含變化點從而使未來的變化不會影響現在的代碼。
6點了，要回了，下次接著寫吧.......o(∩_∩)o...