設計模式複習小結一(Strategy Pattern/Observer Pattern/Decorator Patter/Factory Pattern)

時間 2019-11-30

標籤設計模式複習小結 strategy pattern observer decorator patter factory 欄目 Hadoop 简体版

原文原文鏈接

目錄：html

前言：

　　由於在學習過程當中老是不斷忘記，不少東西也是隻知其一;不知其二，因此學一點就又倒回來再複習一次，第一次學習的時候我主要以實現書中的代碼爲主，而如今複習的時候我就以弄清楚邏輯爲主了，畢竟第一次基本都是隻要能實現功能就大吉大利了。因此此次小階段的複習，我就沒有再在文章中寫代碼了，以畫UML圖爲主，邊弄清楚邏輯，邊搞懂那些知識點。github

　　複習果真是溫故而知新，確實瞭解到了以前比較迷茫的點，可是仍是有不少不明確之處，我以爲應該還須要等把設計模式所有學完一次後再從新倒過來再看一次，可能會有其餘收穫吧。雖然文中全是UML圖，可是全部的例子，在最後個人github中都已經上傳了源代碼，歡迎指教(#^.^#)。算法

　　ppps：在複習的過程我記錄下來整理成博客來分享，可是我以爲我仍是說的不是很清楚，只是本身能靠着UML圖和實例能大概瞭解到本身須要瞭解的知識點，可是介紹出來總是感受哪裏欠缺，我確實須要好好學習一下，怎麼正確表述個人觀點了。固然，這也是須要堅持寫博客的緣由了ヾ(◍°∇°◍)ﾉﾞ，要是個人表述讓您沒法理解，請不吝賜教，讓我慢慢了解到應該怎麼和別人交談。數據庫

返回頂部設計模式

1. Stratrgy Pattern 策略模式

策略模式定義了算法族，分別封裝起來，讓它們之間能夠相互替換，此模式讓算法的變化獨立於使用算法的客戶。安全

解析：

　　策略模式的主要組成部分主要包括Context/Strategy這兩個部分。函數

　　策略類定義了全部支持的算法的公共接口。post

　　其實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，可是必須有須要修飾的對象。