1. 課程簡介
本周開始進(jìn)入到《C++設(shè)計模式》課程中映砖。
A. 課程目標(biāo)
a. 理解松耦合設(shè)計思想
b. 掌握面向?qū)ο笤O(shè)計原則
c. 掌握重構(gòu)技法改善設(shè)計
d. 掌握GOF核心設(shè)計模式
B. 什么是設(shè)計模式
設(shè)計模式描述了一個重復(fù)發(fā)生的問題及該問題解決方案的核心澳迫。其目的在于提高軟件設(shè)計過程中代碼的復(fù)用率魁蒜，提高代碼抵抗變化的能力恩袱。
本課程以面向?qū)ο鬄榛A(chǔ)瓶堕，主要學(xué)習(xí)掌握“好的面向?qū)ο笤O(shè)計”败砂。
2. 面向?qū)ο笤O(shè)計原則
面向?qū)ο笤O(shè)計原則在很多時候比具體的設(shè)計模式更為重要辨嗽，設(shè)計模式是這些設(shè)計原則的實(shí)現(xiàn)世落。
A. 依賴倒置原則(DIP)
- 高層模塊(穩(wěn)定)不應(yīng)該依賴于低層模塊(變化)，二者都應(yīng)該依賴于抽象(穩(wěn)定)糟需。
- 抽象(穩(wěn)定)不應(yīng)該依賴于實(shí)現(xiàn)細(xì)節(jié)(變化)屉佳，實(shí)現(xiàn)細(xì)節(jié)應(yīng)該依賴于抽象(穩(wěn)定)。
B. 開放封閉原則(OCP)
- 對擴(kuò)展開放洲押，對更改封閉武花。
- 類模塊應(yīng)該是可擴(kuò)展的，但是不可修改杈帐。
C. 單一職責(zé)原則(SRP)
- 一個類應(yīng)該僅有一個引起它變化的原因体箕。
- 變化的方向隱含著類的責(zé)任。
D. Liskov 替換原則(LSP)
- 子類必須能夠替換它們的基類(is-a)挑童。
- 繼承表達(dá)類型抽象
E. 接口隔離原則(ISP)
- 不應(yīng)該強(qiáng)迫客戶程序依賴它們不用的方法累铅。
- 接口應(yīng)小而完備。
F. 優(yōu)先使用對象組合站叼，而不是類繼承
- 類繼承通常為“白箱復(fù)用”娃兽，對象組合通常為“黑箱復(fù)用”。
- 繼承在某種程度上破壞了封裝性尽楔，子類父類耦合度高投储。
- 而對象組合則只要求被組合的對象具有良好定義的接口，耦合度低阔馋。
G. 封裝變化點(diǎn)
- 使用封裝來創(chuàng)建對象之間的分界層玛荞，讓設(shè)計者可以在分界層一側(cè)進(jìn)行修改，而不會對另一側(cè)產(chǎn)生不良的影響呕寝，從而實(shí)現(xiàn)層次間的松耦合冲泥。
H. 針對接口編程，而不是針對實(shí)現(xiàn)編程
- 不將變量類型聲明為某個特定的具體類，而是聲明為某個接口凡恍。
- 客戶程序無需獲知對象的具體類型，只需要知道對象所具有的接口怔球。
- 減少系統(tǒng)中各部分的依賴關(guān)系嚼酝，從而實(shí)現(xiàn)“高內(nèi)聚，松耦合”的類型設(shè)計方案竟坛。
3. 從封裝變化角度對模式分類
A. 組件協(xié)作
- Template Method
- Strategy
- Observer / Event
B. 單一職責(zé)
- Decorator
- Bridge
C. 對象創(chuàng)建
- Factory Method
- Abstract Factory
- Prototype
- Builder
D. 對象性能
- Singleton
- Flyweight
E. 接口隔離
- Facade
- Proxy
- Mediator
- Adapter
F. 狀態(tài)變化
- Memento
- State
G. 數(shù)據(jù)結(jié)構(gòu)
- Composite
- Iterator
- Chain of Resposibility
H. 行為變化
- Command
- Visitor
I. 領(lǐng)域問題
- Interpreter
4. 重構(gòu)關(guān)鍵技法
- 靜態(tài)
->動態(tài) - 早綁定
->晚綁定 - 繼承
->組合 - 編譯時依賴
->運(yùn)行時依賴 - 緊耦合
->松耦合
5. “組件協(xié)作”模式
現(xiàn)代軟件專業(yè)分工之后的第一個結(jié)果是“框架與應(yīng)用程序的劃分”闽巩，“組件協(xié)作”模式通過晚期綁定，來實(shí)現(xiàn)框架與應(yīng)用程序之間的松耦合担汤，是二者之間協(xié)作時常用的模式涎跨。
A. 模板方法(Template Method)
-
動機(jī)
在軟件構(gòu)建過程中，對于某一項(xiàng)任務(wù)崭歧，它常常有穩(wěn)定的整體操作結(jié)構(gòu)隅很，但各個子步驟卻有很多改變的需求，或者由于固有的原因(比如框架與應(yīng)用之間的關(guān)系)而無法和任務(wù)的整體結(jié)構(gòu)同時實(shí)現(xiàn)率碾。
如何在確定穩(wěn)定操作結(jié)構(gòu)的前提下叔营，來靈活應(yīng)對各個子步驟的變化或者晚期實(shí)現(xiàn)需求？
優(yōu)化前流程優(yōu)化后流程模式定義結(jié)構(gòu)要點(diǎn)總結(jié)
B. 策略模式(Strategy)
-
動機(jī)
在軟件構(gòu)建過程中所宰，某些對象使用的算法可能多種多樣绒尊，經(jīng)常改變，如果將這些算法都編碼到對象中仔粥，將會使對象變得異常復(fù)雜婴谱；而且有時候支持不使用的算法也是一個性能負(fù)擔(dān)。
如何在在運(yùn)行時根據(jù)需要透明地理性對象的算法躯泰？將算法與對象本身解耦谭羔，從而避免上述問題？
模式定義結(jié)構(gòu)要點(diǎn)總結(jié)
C. 觀察者模式(Observer)
-
動機(jī)
在軟件構(gòu)建過程中斟冕，我們需要為某些對象建立一種“通知依賴關(guān)系”——一個對象(目標(biāo)對象)的狀態(tài)發(fā)生改變口糕，所有的依賴對象(觀察者對象)都將得到通知。如果這樣的依賴關(guān)系過于緊密磕蛇，將使軟件不能很好地抵御變化景描。
使用變身對象技術(shù)，可以將這種依賴關(guān)系弱化秀撇，并形成一種穩(wěn)定的依賴關(guān)系超棺。從而實(shí)現(xiàn)軟件體系結(jié)構(gòu)的松耦合。
模式定義結(jié)構(gòu)要點(diǎn)總結(jié)
6. “單一職責(zé)”模式
在軟件組件的設(shè)計中呵燕，如果責(zé)任劃分不清晰棠绘，使用繼承得到的結(jié)果往往是隨著需求的變化，子類急劇膨脹，同時充斥著重復(fù)代碼氧苍，這時候的關(guān)鍵是劃清責(zé)任夜矗。
A. 裝飾模式(Decorator)
-
動機(jī)
在某些情況下我們可能會“過度地使用繼承來擴(kuò)展對象的功能”，由于繼承為類型引入的靜態(tài)特質(zhì)让虐，使得這種擴(kuò)展方式缺乏靈活性紊撕；并且隨著子類的增多(擴(kuò)展功能的增多)，各種子類的組合(擴(kuò)展功能的組合)會導(dǎo)致更多子類的膨脹赡突。
如何使“對象功能的擴(kuò)展”能夠根據(jù)需要來動態(tài)地實(shí)現(xiàn)对扶？同時避免“擴(kuò)展功能的增多”帶來的子類膨脹問題？從而使得任何“功能擴(kuò)展變化”所導(dǎo)致的影響降為最低惭缰？
模式定義結(jié)構(gòu)要點(diǎn)總結(jié)
B. 橋模式(Bridge)
-
動機(jī)
由于某些類型的固有的實(shí)現(xiàn)邏輯浪南，使得它們具有兩個變化的維度，乃至多個維度的變化漱受。
如何應(yīng)對這種“多維度的變化”络凿？如何利用面向?qū)ο蠹夹g(shù)來使得類型可以輕松地沿著兩個乃至多個方向變化，而不引入額外的復(fù)雜度拜效？
模式定義結(jié)構(gòu)要點(diǎn)總結(jié)
