關於設計模式的總結沒有落實到代碼上，而且設計模式自己確實動手實現的非常少。所以在這一周里，除了看網站開發的視頻，着手開始對設計模式進行實現以下。設計模式非常經典，每次看都有不同的收獲，寫一下自己的收獲吧，請大家指正。
在實現設計模式之前，首先來復習以下UML中的五種關系圖
<1>依賴
依賴關系用虛線加箭頭表示,如圖所示:
上圖表示:Animal類依賴於Water類（動物依賴於水）。
依賴是類的五種關系中耦合最小的一種關系。因為依賴關系在生成代碼的時候，這兩個關系類都不會增加屬性。這種微弱的關系可以用類之間的相互了解的程度來說明。(下圖為代碼生成圖)
由上圖可見生成的代碼中Animal類的屬性中沒有增加Water類。那么Animal類如何使用Water類呢，有三種方式：
依賴關系的三種表現形式：
① Water類是全局的，則Animal類可以調用它
② Water類是Animal類的某個方法中的變量，則Animal類可以調用它。代碼演示如下：
PS：Animal有一個長大（GrownUp）方法，Water類作為該方法的變量來使用。
請注意Water類的生命期，它是當Animal類的GrounUp方法被調用的時候，才被實例化。
持有Water類的是Animal的一個方法而不是Animal類，這點是最重要的。
③ Water類是作為Animal類中某個方法的參數或者返回值時。代碼演示如下
無用多說，Water類被Animal類的一個方法持有。生命期隨着方法的執行結束而結束。
在依賴關系中，必須采用這三種方法之一。
<2>關聯
關聯是實線加箭頭表示。表示類之間的耦合度比依賴要強。has a
例：水與氣候是關聯的，表示圖如下
生成代碼如下：
可見生成的代碼中，Water類的屬性中增加了Climate類。
關聯既有單向關聯又有雙向關聯。
單向關聯：Water類和Climate類單向關聯（如下圖），則Water類稱為源類，Climate類稱為目標類。源類了解目標類的所有的屬性和方法，但目標類並不了解源類的信息。
雙向關聯：源類和目標類相互了解彼此的信息。如將Water類和Climate類之間改為雙向關聯，如下圖
依賴和關聯的區別：
① 從類的屬性是否增加的角度看：
發生依賴關系的兩個類都不會增加屬性。其中的一個類作為另一個類的方法的參數或者返回值，或者是某個方法的變量而已。
發生關聯關系的兩個類，其中的一個類成為另一個類的屬性，而屬性是一種更為緊密的耦合，更為長久的持有關系。
② 從關系的生命期角度看：
依賴關系是僅當類的方法被調用時而產生，伴隨着方法的結束而結束了。
關聯關系是當類實例化的時候即產生，當類銷毀的時候，關系結束。相比依賴講，關聯關系的生存期更長。
關聯關系的細化
關聯關系又可以細化為聚合關系和組合關系
聚合關系圖：
組合關系圖：
l 聚合和組合的區別：
由於聚合和組合都是特殊的關聯關系，在生成的代碼上看不出區別，都是關聯的形式。那到底這兩種關系如何來區分呢。
區分的關鍵有兩點：
① 構造函數不同
聚合關系下：雁群類（GooseGroup）和大雁類（Goose）代碼如下：
組合關系下：大雁類（Goose）和翅膀類（Wings）代碼如下：
這兩種關系的區別在於：
①構造函數不同
聚合類的構造函數中包含了另一個類作為參數。
雁群類（GooseGroup）的構造函數中要用到大雁（Goose）作為參數傳遞進來。大雁類（Goose）可以脫離雁群類而獨立存在。
組合類的構造函數中包含了另一個類的實例化。
表明大雁類在實例化之前，一定要先實例化翅膀類（Wings），這兩個類緊密的耦合在一起，同生共滅。翅膀類（Wings）是不可以脫離大雁類（Goose）而獨立存在
② 信息的封裝性不同
在聚合關系中，客戶端可以同時了解雁群類和大雁類，因為他們都是獨立的
而在組合關系中，客戶端只認識大雁類，根本就不知道翅膀類的存在，因為翅膀類被嚴密的封裝在大雁類中。
<3>泛化
泛化就是一個類繼承另一個類所有的描述，並且可以根據需要對父類進行拓展，是面向對象的重要特征之一。
泛化使用一根實線加箭頭，泛化關系圖 is a
泛化的用處：①實現了代碼的復用
②實現了多態
<4>實現
主要針對接口和抽象類而言，實現接口和抽象類的類必須要實現他們的方法。
實現關系表示為：虛線加箭頭，關系圖如下：
接口只包含方法、委托或事件的簽名。方法的實現是在實現接口的類中完成的。
關於泛化關系和實現關系比較簡單，這里就不一一展開了。了解清楚了這幾種關系以及他們的代碼特點，才能更好的學習設計模式！
article from “http://blog.csdn.net/backzero/article/details/7488535”