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

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

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

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

3、面向?qū)ο蟮姆妒剑菏褂脤ο髮⒇熑无D(zhuǎn)義到更局部的范圍。對象應該對自己負責，并且這種責任應該被清楚的定義出來。

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

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

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

5、過早的對細節(jié)投入過多的關(guān)心是一個分析缺陷。

評論：同2。

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

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

7、關(guān)注模式的場景而非解決方案。

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

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

   a、發(fā)現(xiàn)并封裝變化點。

   b、優(yōu)先使用對象組合，而非類繼承。

評論：關(guān)于共同點/變化點的分析，在Bridge模式中體現(xiàn)的猶為明顯（我在前面的Blog中介紹過），借助分析矩陣也可以幫助理清思路。而b點是面向?qū)ο笤O(shè)計中的基本原則，就不用多說了。

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

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

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

步驟：

（1）、發(fā)現(xiàn)我在問題領(lǐng)域中擁有的模式

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

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

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

   c、識別任何可能已經(jīng)出現(xiàn)的附加模式。將它們添加到“需要分析的模式”中。

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

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

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

11、在學習面向?qū)ο蠹夹g(shù)的早期學習設(shè)計模式，可以大大幫助你提高對面向?qū)ο蠓治觥⒃O(shè)計的理解。

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