再回首行為型設計模式

行為型

設計模式被分成三大類，建立型，結構型，行為型。具體要闡述為什麼這麼分，這個問題，暫時解決不了，但是我們能做的是，合理的運用它。對於行為型設計模式，區別於其他兩種的就是：它側重的是對「方法」的操作。

下面是對幾個行為型的設計模式的理解。

一、模板方法

1、概述

將乙個操作的演算法的骨架和具體演算法實現分離——解耦

骨架在父類中，演算法延遲到子類實現，就可以有n多實現——多型的體現

回顧一下類圖，看看模板解決的問題：

模板的眼:；解決**重複，會

演算法有既定順序。

2、改造模板----演算法骨架靈活

演算法的骨架是既定的，可以修改嗎？要不要修改？

這裡的演算法骨架順序跟建造模式類似，順序基本是穩定。怎麼說呢？

一般使用這兩種模式的「事物」，它的構成順序都是穩定的，不是經常需要變動的，這是乙個前提，但是並不是說，這個順序一定不可以改變，為了靈活程式設計，可以通過委託來實現。往委託佇列註冊的過程就是排序的過程，委託是一大塊，不多說了。

子類可以擴充套件父類嗎？

當然是可以擴充套件的，因為是繼承呀。但是個人認為沒有多大意義。如果只是為了新增方法到子類中，跟複寫方法無關聯，那就是有點破壞單一原則的味道了。

3、建造模式vs模板模式

相同:都有既定的順序，僅此而已。

不同:兩個設計模式的適用範圍不同，解決問題不同，乙個是建立型，乙個是行為型，其他就不用囉嗦了吧。

二、觀察者

1、觀察者的幾點認識

主題與觀察物件，觀察物件之間都是陌生的。一方負責變化，通知；一方負責接收，做出對應變化。

生活中的例項:訂閱**。

通過類圖來分析觀察者的優缺點：

優點:解耦是觀察者的一大特色。通過依賴倒轉，面向介面程式設計的思想，給多個觀察者增加父類介面，讓被通知者成為主動觀察者，來實現觀察者和主題的銜接。

不足:主題只能和一種型別的觀察者進行關聯——從途中可以看出所有的觀察者都是繼承自乙個父類：observer，所以這些觀察者都是乙個父類，要想增加多個型別的觀察者，便有心無力了。

2、觀察模式高階委託

那要是我想通知多個型別的觀察者怎麼辦？答案還是——委託

想要通知其他型別的觀察者，需要如下改動:最大的侷限就是這個抽象的介面——observer，那麼就把它去掉。

抽象類不存在，那麼主題中通知的方法（notify）就沒有意義了，也去掉。

將動態通知觀察者的權利從主題移交給呼叫者。——主題和觀察者徹底解耦。

宣告委託，在呼叫短端註冊各種型別的觀察者，執行呼叫。

三、策略模式:封裝演算法，演算法變化不影響使用者使用。

（具體的在上篇部落格中已經寫到了）

總結：行為型的設計模式還有：職責鏈，命令，解釋，迭代，中介者，備忘錄，狀態，訪問者模式。這裡只寫了三個，其他的幾個沒有這幾個上手。對於剩下的幾個模式：我們本著乙個這樣的原則：what？when？how？

再回首 行為型設計模式