1、模式是應該結合在一起共同解決問題的。

評論：以前看《GOF設計模式》的時候主要就是看目的，然后就是代碼，對協作啊，優缺點啊，效果啊都不怎么注意，不過就算看了也不知所云。學下來就像背數學公式一樣，單個是記住了，拿到具體環境里又懵了。看來還是得多花點時間看看模式的關聯啊。

2、我的錯誤是：我嘗試先創建問題領域中的累，然后將這些類縫合起來形成最終的系統。——Alexander把這樣的過程稱為一個“壞主意”。我從來沒有問過我自己：我是否擁有正確的類？僅僅因為這些類看起來如此正確、如此明顯。我擁有的是在開始分析時立刻進入腦海中的類，是我們的老師告訴我們應該在系統中尋找的“名詞”。但是我的錯誤就是僅僅嘗試把它們簡單地放在一起。

評論：連大牛都會犯這樣的錯誤，我這樣的菜鳥這樣分析系統應該也比較正常吧。在看問題的層次上，我們太過于重視細節，就像我寫WinForm程序時先考慮有哪些組件可以使用一樣，把思路給限制住了，忽視了類所處的環境、上下文。

3、面向對象的范式：使用對象將責任轉義到更局部的范圍。對象應該對自己負責，并且這種責任應該被清楚的定義出來。

評論：這個對類的定義就要合理的多。作者認為軟件開發中有三個視角：概念（用例）－>規格（接口）－>實現（代碼）。從最低層次看，類就是變量+函數，但這樣就太狹隘了。真正的對象應該與現實生活中的對象相似，有自己的行為、狀態，自己對自己負責（多么精確的概述啊）。

4、抽象類就是其他類的占位符。

評論：比較形象的描述。我先描述類的大致行為供調用者了解，具體的行為留到子類實現，抽象類與子類達成一個契約。

5、過早的對細節投入過多的關心是一個分析缺陷。

評論：同2。

6、留意你的直觀：當你看到某些不喜歡的東西時，你胃部的感覺。

評論：牛人就是幽默。這里主要是說明如何感覺一個設計是壞的設計的。我是說最近寫程序胃老不舒服，飯也吃不好……

7、關注模式的場景而非解決方案。

評論：作者自始至終一直強調是場景決定解決方案，而不是為了實現某個模式而去進行設計，否則就像小學生套公式一樣了。場景分析好了，模式自然也就出來了（這是境界比較高的時候）。

8、在創建對象時用共同點/變化點分析而非觀察名詞與動詞。因此，我們要：

   a、發現并封裝變化點。

   b、優先使用對象組合，而非類繼承。

評論：關于共同點/變化點的分析，在Bridge模式中體現的猶為明顯（我在前面的Blog中介紹過），借助分析矩陣也可以幫助理清思路。而b點是面向對象設計中的基本原則，就不用多說了。

9、switch語句常常標志著：（1）對多態行為的需要。（2）存在著放錯地方的責任。請考慮用一種更普適的解決方案代替switch語句，比如抽象、將責任分配給另外的對象等等。

評論：老聽別人說丑陋的switch語句、ifelse語句，都不是太懂，現在好像有點懂了，因為條件語句不靈活，很難維護吧。碰到它馬上就要想到用多態的方式去處理，像State模式、Visitor模式就和這有關。

10、用模式的方法去思考：

步驟：

（1）、發現我在問題領域中擁有的模式

（2）、對于這些需要分析的模式，做下列工作：

   a、挑出為其他模式提供最多場景的模式。

   b、在我概念性最高的設計中使用這個模式。

   c、識別任何可能已經出現的附加模式。將它們添加到“需要分析的模式”中。

   d、對需要分析而未分析的模式，重復上述工作。

（3）、按照需要將細節添加的設計中。擴展方法和類定義。

評論：具體的說就是找到可以統領全局的模式，再用其他的模式配合它，“面向模式的設計”(POP)。算了吧，我連OOP都沒學好，這個以后再說啦。

11、在學習面向對象技術的早期學習設計模式，可以大大幫助你提高對面向對象分析、設計的理解。

評論：這個倒是第一次聽說，不過怎么也得先把繼承、封裝、多態弄清楚吧。再加上一條，在學習設計模式時，一定要先讀這本《設計模式精解》，再看《GOF設計模式》，。