目錄： 前言 1. Stratrgy Pattern 2. Observer Pattern 3. Decorator Pattern 4. Factory Pattern 4.1 FactoryPattern 4.2 AbstractFactoryPattern 總結 4.1 FactoryPat ...
目錄：
前言：
因為在學習過程中總是不斷忘記，很多東西也是一知半解，所以學一點就又倒回來再複習一次，第一次學習的時候我主要以實現書中的代碼為主，而現在複習的時候我就以弄清楚邏輯為主了，畢竟第一次基本都是只要能實現功能就大吉大利了。所以這次小階段的複習，我就沒有再在文章中寫代碼了，以畫UML圖為主，邊弄清楚邏輯，邊搞懂那些知識點。
複習果然是溫故而知新，確實瞭解到了之前比較迷茫的點，但是還是有很多不明確之處，我覺得應該還需要等把設計模式全部學完一次後再重新倒過來再看一次，可能會有其他收穫吧。雖然文中全是UML圖，但是所有的例子，在最後我的github中都已經上傳了源代碼，歡迎指教(#^.^#)。
ppps：在複習的過程我記錄下來整理成博客來分享，但是我覺得我還是說的不是很清楚，只是自己能靠著UML圖和實例能大概瞭解到自己需要瞭解的知識點，但是介紹出來老是感覺哪裡欠缺，我確實需要好好學習一下，怎麼正確表述我的觀點了。當然，這也是需要堅持寫博客的原因了ヾ(◍°∇°◍)ﾉﾞ，要是我的表述讓您無法理解，請不吝賜教，讓我慢慢瞭解到應該怎麼和別人交談。
1. Stratrgy Pattern 策略模式
策略模式定義了演算法族，分別封裝起來，讓它們之間可以相互替換，此模式讓演算法的變化獨立於使用演算法的客戶。
解析：
策略模式的主要組成部分主要包括Context/Strategy這兩個部分。
策略類定義了所有支持的演算法的公共介面。
其實StrategyPattern就是將代碼儘量的變小，各部分功能儘量單一化，將相似的功能放進同一個函數或者介面里，這個函數或者介面也就是ConcreteStrategyABC了。
實例解析1：
詳細解釋：C#學習筆記-策略模式
這裡將優惠的方式分為三種，1：正常收費；2：折扣；3.滿減活動；題目中所提到的優惠方式不外乎這三種，所以將優惠方式做成一個介面CashSuper，然後往下再分支成三種具體的優惠方式，這樣我們要是某一種優惠方式有變動，直接去具體的那種優惠方式中修改即可，同時，要是添加了新的優惠方式，直接繼承CashSuper這個介面，然後添加新的實現方式就好了，這樣保證了原來代碼的安全，也添加了新的功能。這也是我們的設計原則：封裝變化。
實例解析2：
我們設計一些鴨子，這些鴨子有：綠頭鴨、紅頭鴨、橡皮鴨、誘餌鴨等，他們有各自的外貌特征，同時有各自不同的叫聲，有的鴨子例如綠頭鴨可以飛行，但是橡皮鴨這些卻不能飛行。請設計出這些鴨子。
解析：
鴨子的外貌可以設定為屬性，但是叫聲和飛行就是兩種動作，且有不同種情況：飛行FlyBehavior有兩種（FlyWithWings/FlyNoWay兩種具體的不同的實現行為），叫聲QuackBehavior有很多種情況（例如：Quack/Squeak/MuteQuack），所以我們將飛行行為和叫聲這兩種行為封裝起來，這樣保證了不同的鴨子調用自己不同的行為即可，同時保證瞭如果添加了新的鴨子又有新的行為時，方便添加新的具體的行為進來。
具體實現：
小結：
好的代碼就是讓代碼變得易維護，而這就是策略模式最大的優點。
2. Observer Pattern 觀察者模式
觀察者模式定義了一種一對多的依賴關係，讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀態發生變化時，會通知所有的觀察者對象，使他們能夠自動更新自己。
解析：
觀察者模式重要的是Subject/Observer這兩個介面。
Subject：他把所有對觀察者對象的引用保存在一個聚集里，每個主題都可以有任何數量的觀察者。抽象主題提供了一個介面，可以刪除和增加觀察者對象。
Observer：抽象觀察者，為所有的具體觀察者定義一個介面，在得到主題的通知時更新自己。
抽象模式有兩個方面，其中一個人方面依賴於另一個方面，這時用觀察者模式可以將這兩者封裝在獨立的對象中使它們各自獨立的改變和復用。
實例解析1：
詳細解釋：C#學習筆記-觀察者模式
對於具體的Observer而言（也就是MemberOne和MemberTwo），具體的Subject是誰，他們並不需要知道，只要作為Subject的那個人將有用的信息傳遞給他們就好了。同理，作為具體的Subject而言，不需要知道每一個Observer是誰，只需要在信息更新的時候，將有用的信息傳遞給在他那註冊了的成員就好了。這就實現了軟體設計的一個重要原則：為交互對象之間的松耦合設計而努力。
實例解析2：
現在需要建立氣象觀測站的一個應用：目前有三種佈告板，分別顯示目前的狀況、氣象統計即簡單的預報。當WeatherObject對象獲得最新的測量數據時，三種佈告板必須實時更新。
解析：
這個題目很明顯符合了OberverPattern要求，三個佈告板理所當然地就是具體的Observer了，獲取各種信息的WeatherData就是具體的Subject了。
具體實現：
小結：
松耦合設計更加有彈性，更能應對變化。
3. Decorator Pattern 裝飾模式
裝飾模式，動態地給一個對象添加一些額外的職責。
解析：
不管是ConcreteComponent還是Decorator，亦或是ConcreteDecoratorABC,他們都繼承來自於Component，所以所有的一切都相當於是對Component功能的擴展，這也就是裝飾模式的意義。
實例解析1：
解析：
詳細解釋：C#學習筆記-裝飾模式
只需要註意一點：服飾作為裝飾品，需要專門記住他需要裝飾的對象，不然裝飾就沒有任何意義了。
實例解析2：
我們現在來做飲料，每一種飲料有不同的配料，每一種配料價格不一樣，名字不一樣，例如：現在顧客想要一杯加了奶泡和摩卡的深烘焙，我們需要得到各種搭配的飲料的價格。
解析：
首先具體的飲料例如上面說的“深烘焙”在這裡就是具體的Component了，那些奶泡或者摩卡都是為了修飾他而存在的，所以同理，奶泡和摩卡之類就是ConcereteDecoratorABC了。仍然要註意的是奶泡那些不許攜帶他們需要修飾的對象Beverage，不用指定具體修飾的哪一種Beverage，但是必須有需要修飾的對象。
具體實現：
小結：
好的代碼是對擴展開放，對修改關閉。
4. Factory Pattern 工廠模式
4.1 FactoryPattern工廠模式
工廠模式，定義一個用於創建對象的介面，讓子類決定實例化哪一個類。
解析：
需要註意的是：工廠方法必須要返回一個Product類型的對象，因為工廠方法的唯一的作用就是實例化一個Product。
實例解析1：
寫一個簡單的電腦。
解析：
將計算中的加減乘除分為四個類，這樣可以相互不幹擾，但是都繼承於計算這個類，然後建立OperationFactory來通過用戶傳輸進來的符號來判斷到底我們需要調用那種計算方式，也就是實例化哪一種類。
具體實現：
詳細解釋：C#學習筆記-工廠模式
實例解析2：
我們現在開披薩連鎖店，在紐約、芝加哥和加州開披薩連鎖店，不同的地區根據當地人的口味設計不同味道的同披薩。
解析：
現在作為客人的我們要選擇披薩的時候，店家首先需要根據我們的選擇來確定是哪個地區的哪種風味的披薩，所以這個時候需要實例化的就是根據選擇的披薩來實例化該地區的那種風味的披薩。
具體實現：
小結：
設計原則：依賴抽象，不要依賴具體類。
4.2 AbstractFactoryPattern抽象工廠模式
抽象工廠模式提供一個介面，用於創建相關或依賴對象的家族，而不需要明確指出具體類。
解析：
抽象工廠模式與工廠模式的區別在於，工廠模式只是創建一個產品，而抽象工廠模式是創建產品家族，並讓製造的產品集合起來使用。
所以抽象工廠模式需要一個大的介面AbstractFactory，而他具體的實現ConcreteFactory12345裡面的具體實例化可以調用工廠模式。
實例分析1：
解析：
這裡的資料庫不定，表單數不定，但是彼此之間都可能存在關係，所以可以調用抽象工廠模式將這一系列的產品想關聯起來。
具體實現：C#學習筆記-抽象工廠模式
實例分析2：
現在我們建立一個工廠來生產原料；這個工廠將負責創建原料家族中的每一種原料，為披薩店提供原材料
解析：
我們訂購了pizza後，商店自己根據當前訂購的pizza獲得當前需要在哪家店訂購披薩，然後當地的pizza在從當地的原料工廠獲得製作pizza 的原料，如此來製作披薩。
具體實現：
這裡的原料家族生成各種各樣的產品，再通過不同的組合組成，組成我們所需要的披薩，所以這個部分我們需要調用抽象工廠模式。
小結：
抽象工廠模式創建產品家族，工廠模式創建一個產品。
總結：
溫故而知新
成長就是不斷發現以前的自己是個傻逼
備註：源代碼示例My Github
