1. 設(shè)計(jì)模式簡(jiǎn)介

課程目標(biāo)

• 理解松耦合設(shè)計(jì)思想
• 掌握面向?qū)ο笤O(shè)計(jì)原則
• 掌握重構(gòu)技法改善設(shè)計(jì)
• 掌握GOF 核心設(shè)計(jì)模式

什么是設(shè)計(jì)模式

“每一個(gè)模式描述了一個(gè)在我們周圍不斷重復(fù)發(fā)生的問題，以及該問題的解決方案的核心。這樣，你就能一次又一次地使用該方案而不必做重復(fù)勞動(dòng)。”

GOF 設(shè)計(jì)模式

• 歷史性著作《設(shè)計(jì)模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ)》一書中描述了23種經(jīng)典面向?qū)ο笤O(shè)計(jì)模式，創(chuàng)立了模式在軟件設(shè)計(jì)中的地位。
  可復(fù)用是一個(gè)設(shè)計(jì)目標(biāo)，面向?qū)ο笫鞘址?/li>
• 由于《設(shè)計(jì)模式》一書確定了設(shè)計(jì)……
  還有其他的模式
  架構(gòu)模式
  數(shù)據(jù)庫模式

從面向?qū)ο笳勂?/h2>

• 底層思維：向下，如何把握機(jī)器底層從微觀理解對(duì)象構(gòu)造
  • 語言構(gòu)造
  • 編譯轉(zhuǎn)換
  • 內(nèi)存模型
  • 運(yùn)行時(shí)機(jī)制
• 抽象思維：向上，如何將我們的周圍世界抽象為程序代碼
  • 面向?qū)ο?/li>
  • 組建封裝
  • 設(shè)計(jì)模式
  • 架構(gòu)模式

深入理解面向?qū)ο?/h2>

• 向下：深入理解三大面向?qū)ο髾C(jī)制
  • 封裝，隱藏內(nèi)部實(shí)現(xiàn)
  • 繼承，復(fù)用現(xiàn)有代碼
  • 多態(tài)，改寫對(duì)象行為
• 向上：深刻把握面向?qū)ο髾C(jī)制所帶來的抽象意義，理解如何使用這些機(jī)制來表達(dá)現(xiàn)實(shí)世界，掌握什么是“好的面向?qū)ο笤O(shè)計(jì)”
  評(píng)判好壞要看抽象機(jī)制

軟件設(shè)計(jì)固有的復(fù)雜性

建筑商從來不會(huì)去想給一棟已建好的100層高的樓房底下再新修一個(gè)小地下室……

軟件設(shè)計(jì)復(fù)雜的根本原因

變化

• 客戶需求的變化
• 技術(shù)平臺(tái)的變化
• 開發(fā)團(tuán)隊(duì)的變化
• 市場(chǎng)環(huán)境的變化
  ……

如何解決復(fù)雜性？

• 分解
  人們面對(duì)復(fù)雜性有一個(gè)常見的做法：即分而治之，將大問題分解為多個(gè)小問題，將復(fù)雜問題分解為多個(gè)簡(jiǎn)單問題。
• 抽象
  更高層次來講，人們處理復(fù)雜性有一個(gè)通用的技術(shù)，即抽象出由于不能掌握全部的復(fù)雜對(duì)象，我們選擇忽視它的非本質(zhì)細(xì)節(jié)，而去處理泛化和理想化了的對(duì)象模型。

重要的建立一些思想和模型。

舉例

Shape1（分解）
Shape2（抽象）
基類最好要有虛的析構(gòu)函數(shù)。
所有繼承最好都要用public的繼承。
多態(tài)性->指針
第一種如果要變更，需要在所有涉及的地方修改。
第二種如果要變更，如果使用工廠模式，只需要增加一個(gè)子類。重用性得到了很高的提升。

軟件設(shè)計(jì)的目標(biāo)

什么是好的軟件設(shè)計(jì)？軟件設(shè)計(jì)的金科玉律：

復(fù)用！

2. 面向?qū)ο笤O(shè)計(jì)原則

面向?qū)ο笤O(shè)計(jì)，為什么？

變化是復(fù)用的天敵！
面向?qū)ο笤O(shè)計(jì)最大的優(yōu)勢(shì)在于：

抵御變化

重新認(rèn)識(shí)面向?qū)ο?/h2>

• 理解隔離變化
  • 從宏觀層面來看，面向?qū)ο蟮臉?gòu)建方式更能適應(yīng)軟件的變化，能將變化所帶來的影響減為最小。
• 各司其職
  • 從微觀層面來看，面向?qū)ο蟮姆绞礁鼜?qiáng)調(diào)各類的“責(zé)任”
  • 適用于需求變化導(dǎo)致的新增類型不應(yīng)該影響原來類型的實(shí)現(xiàn)——是所謂各負(fù)其責(zé)
• 對(duì)象是什么？
  • 從語言實(shí)現(xiàn)層面來看，對(duì)象封裝了代碼和數(shù)據(jù)。
  • 從規(guī)格層面講，對(duì)象是一系列可被使用的公共接口。
  • 從概念層面講，對(duì)象是某種擁有責(zé)任的抽象。

面向?qū)ο笤O(shè)計(jì)原則（1/8）

• 以來倒置原則（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)定）。

MainForm（依賴）->Line Rect
MainForm（依賴）->Shape<-（依賴）Line Rect

面向?qū)ο笤O(shè)計(jì)原則（2）

• 開放封閉原則（OCP）
  • 對(duì)擴(kuò)展開放，對(duì)更改封閉。
  • 類模塊應(yīng)該是可擴(kuò)展的，但是不可修改。

面向?qū)ο笤O(shè)計(jì)原則（3）

• 單一職責(zé)原則（SRP）
  • 一個(gè)類應(yīng)該僅有一個(gè)引起它變化的原因。
  • 變化的方向隱含著類的責(zé)任。

面向?qū)ο笤O(shè)計(jì)原則（4）

• Liskov替換原則（LSP）
  • 子類必須能夠替換它們的基類（IS-A）。
  • 繼承表達(dá)類型抽象。

面向?qū)ο笤O(shè)計(jì)原則（5）

• 接口隔離原則（ISP）
  • 不應(yīng)該強(qiáng)迫客戶依賴它們不用的方法。
  • 接口應(yīng)該小而完備。

一旦產(chǎn)生依賴，就必須保持穩(wěn)定。

面向?qū)ο笤O(shè)計(jì)原則（6）

• 優(yōu)先使用對(duì)象組合，而不是類繼承
  • 類繼承通常為“白箱復(fù)用”，對(duì)象組合通常為“黑箱復(fù)用”。
  • 繼承在某種程度上破壞了封裝性，子類父類耦合度高。
  • 而對(duì)象組合則要求被組合的對(duì)象具有良好定義的接口耦合度低。

面向?qū)ο笤O(shè)計(jì)原則（7）

• 封裝變化點(diǎn)
  使用封裝來創(chuàng)建對(duì)象之間的分界層，讓設(shè)計(jì)者可以在分界層的一側(cè)進(jìn)行修改，而不會(huì)對(duì)另一側(cè)產(chǎn)生不良影響從而實(shí)現(xiàn)層次間的松耦合。

面向?qū)ο笤O(shè)計(jì)原則（8）

• 針對(duì)接口編程，而不是針對(duì)實(shí)現(xiàn)變成
  • 不將變量類型聲明為某個(gè)特定的具體類，而是聲明為某個(gè)接口。
  • 客戶程序無需獲知對(duì)象的具體類型，只需要知道對(duì)象所具有的接口。
  • 減少系統(tǒng)中各部分的依賴關(guān)系，從而實(shí)現(xiàn)“高內(nèi)聚、松耦合”的類型設(shè)計(jì)方案。

面向接口設(shè)計(jì)

產(chǎn)業(yè)強(qiáng)盛的標(biāo)志

接口標(biāo)準(zhǔn)化！

分工協(xié)作，通過分工實(shí)現(xiàn)復(fù)用性。

以史為鑒（1）

秦為什么能夠統(tǒng)一六國(guó)？
根據(jù)史書記載和考古發(fā)現(xiàn)，秦的兵器不論東南西北，出土地點(diǎn)都有統(tǒng)一的標(biāo)準(zhǔn)，包括劍，戈，弩，甚至弩機(jī)，弩體，箭頭都是一樣的。而其他六國(guó)則不是。

以史為鑒（2）

畢升的活字印刷為什么成為四大發(fā)明，推動(dòng)了人類文明的前進(jìn)？
畢升之前的雕版印刷將字刻死在木板或石板上……

將設(shè)計(jì)原則提升為設(shè)計(jì)經(jīng)驗(yàn)

1. 設(shè)計(jì)習(xí)語 Design Idioms
   Design Idioms 描述與特定編程語言相關(guān)的低層模式，技巧，慣用法。
2. 設(shè)計(jì)模式 Design Patterns
   Design Patterns 主要描述的是“類與相互通信對(duì)象之間的組織關(guān)系，包括它們的角色、職責(zé)、協(xié)作方式等方面。
3. 架構(gòu)模式 Architectural Patterns
   Architectural Patterns 描述系統(tǒng)中與基本結(jié)構(gòu)組織關(guān)系密切的高層模式，包括子系統(tǒng)劃分，職責(zé)，以及如何組織它們之間關(guān)系的規(guī)則。

3. 模板方法 Template Method

GOF-23 模式分類

• 從目的來看：
  • 創(chuàng)建型（Creational）模式：將對(duì)象的部分創(chuàng)建工作延遲到子類或者其他對(duì)象，從而應(yīng)對(duì)需求變化為對(duì)象創(chuàng)建時(shí)具體類型實(shí)現(xiàn)引來的沖擊。
  • 結(jié)構(gòu)型（Structural）模式：通過類繼承或者對(duì)象組合獲得更靈活的結(jié)構(gòu)，從而應(yīng)對(duì)需求變化為對(duì)象的結(jié)構(gòu)帶來的沖擊。
  • 行為型（Behavioral）模式：通過類繼承或者對(duì)象組合來劃分類與對(duì)象間的職責(zé)，從而應(yīng)對(duì)需求變化為多個(gè)交互的對(duì)象帶來的沖擊。
• 從范圍來看：
• 類模式處理類與子類的靜態(tài)關(guān)系。（集成）
• 對(duì)象模式處理對(duì)象間的動(dòng)態(tài)關(guān)系。 （組合）

從封裝變化角度對(duì)模式分類

• 組件協(xié)作：
  • Template Method
  • Strategy
  • Observer/Event
• 單一職責(zé)：
  • Decorator
  • Bridge
• 對(duì)象創(chuàng)建：
  • Factory Method
  • Abstract Factory
  • Prototype
  • Builder
• 對(duì)象性能：
• Singleton
• Flyweight
• 接口隔離：
  • Facade
  • Proxy
  • Mediator
  • Adapter
• 狀態(tài)變化：
  • Memento
  • State
• 數(shù)據(jù)結(jié)構(gòu)：
  • Composite
  • Iterator
  • Chain of Responsibility
• 行為變化：
  • Command
  • Visitor
• 領(lǐng)域問題：
  • Interpreter

重構(gòu)獲得模式 Refactoring to Patterns

• 面向?qū)ο笤O(shè)計(jì)模式是“好的面向?qū)ο笤O(shè)計(jì)”，所謂“好的面向?qū)ο笤O(shè)計(jì)”指的是那些可以滿足“應(yīng)對(duì)變化，提高復(fù)用”的設(shè)計(jì)。
• 現(xiàn)代軟件設(shè)計(jì)的特征是“需求的頻繁變化”。設(shè)計(jì)模式的要點(diǎn)是“尋找變化點(diǎn)，然后在變化點(diǎn)處應(yīng)用設(shè)計(jì)模式，從而來更好地應(yīng)對(duì)需求的變化”。“什么時(shí)候、什么地點(diǎn)應(yīng)用設(shè)計(jì)模式”比“理解設(shè)計(jì)模式結(jié)構(gòu)本身”更為重要。
• 設(shè)計(jì)模式的應(yīng)用不宜先入為主，一上來就使用設(shè)計(jì)模式是對(duì)設(shè)計(jì)模式的最大誤用。沒有一步到位的設(shè)計(jì)模式。敏捷軟件開發(fā)實(shí)踐提倡的“Refactoring to Patterns”是目前普遍公認(rèn)的最好的使用設(shè)計(jì)模式的方法。

推薦圖書

重構(gòu)——改善既有代碼的設(shè)計(jì)
Refactoring to Patterns 重構(gòu)與模式

重構(gòu)關(guān)鍵技法

• 靜態(tài) → 動(dòng)態(tài)
• 早綁定 → 晚綁定
• 繼承 → 組合
• 編譯時(shí)依賴 → 運(yùn)行時(shí)依賴
• 緊耦合 → 松耦合

是從不同角度談一個(gè)問題

“組件協(xié)作”模式：

• 現(xiàn)代軟件專業(yè)分工之后的第一個(gè)結(jié)果是“框架與應(yīng)用程序的劃分”，“組件協(xié)作”模式通過晚期綁定，來實(shí)現(xiàn)框架與應(yīng)用程序之間的松耦合，使二者之間協(xié)作時(shí)常用的模式。
• 典型模式
  • Template Method
  • Strategy
  • Observer / Event

Template Method

動(dòng)機(jī)（Motivation）

• 在軟件構(gòu)建過程中，對(duì)于某一項(xiàng)任務(wù)，它常常有穩(wěn)定的整體操作結(jié)構(gòu)，但各個(gè)子步驟卻有很多改變的需求，或者由于固有的原因（比如框架與應(yīng)用之間的關(guān)系）而無法和任務(wù)的整體結(jié)構(gòu)同時(shí)實(shí)現(xiàn)。
• 如何在確定穩(wěn)定操作結(jié)構(gòu)的前提下，來靈活應(yīng)對(duì)各個(gè)子步驟的變化或者晚期實(shí)現(xiàn)需求？

基類一定要寫虛的析構(gòu)函數(shù)

結(jié)構(gòu)化軟件設(shè)計(jì)流程

面向?qū)ο筌浖O(shè)計(jì)流程

早綁定與晚綁定

常見方式

將過程寫到庫中，過程中留有虛函數(shù)，在復(fù)用時(shí)定義虛函數(shù)。
縱向的靈活性。

模式定義

定義一個(gè)操作中的算法的骨架（穩(wěn)定），而將一些步驟延遲（變化）到子類中。Template Method 使得子類可以不改變（復(fù)用）一個(gè)算法的結(jié)構(gòu)即可重定義（override 重寫）該算法的某些特定步驟。
——《設(shè)計(jì)模式》Gof
穩(wěn)定是指的相對(duì)穩(wěn)定，變化只是相對(duì)不穩(wěn)定。

結(jié)構(gòu)（Structure）

結(jié)構(gòu)（Structure）

TemplateMethod() 穩(wěn)定
PrimitiveOperation() 變化
每次遇到Lib，都要知道哪些是穩(wěn)定的部分，哪些是不穩(wěn)定的部分。

要點(diǎn)總結(jié)

• Template Method 模式是一種非常基礎(chǔ)性的設(shè)計(jì)模式，在面向?qū)ο笙到y(tǒng)中有著大量的應(yīng)用。它用最簡(jiǎn)潔的機(jī)制（虛函數(shù)的多態(tài)性）為很多應(yīng)用程序框架提供了靈活的擴(kuò)展點(diǎn)（繼承+多態(tài)），是代碼復(fù)用方面的基本實(shí)現(xiàn)結(jié)構(gòu)。
• 除了可以靈活應(yīng)對(duì)子步驟的變化外，“不要調(diào)用我，讓我來調(diào)用你”的反向控制結(jié)構(gòu)是 Template Method 的典型應(yīng)用。
• 在具體實(shí)現(xiàn)方面，被 Template Method 調(diào)用的虛方法可以具有實(shí)現(xiàn)，也可以沒有任何實(shí)現(xiàn)（抽象方法、純虛方法），但一般推薦將它們?cè)O(shè)置為 protected 方法。

4. 策略模式

策略模式（Strategy）

動(dòng)機(jī)（Motivation）

• 在軟件構(gòu)建過程中，某些對(duì)象使用的算法可能多種多樣，經(jīng)常改變，如果將這些算法都編碼到對(duì)象中，將會(huì)使對(duì)象變得異常復(fù)雜；而且有時(shí)候支持不使用的算法也是一個(gè)性能負(fù)擔(dān)。
• 如何在運(yùn)行時(shí)根據(jù)需要透明地更改對(duì)象的算法？將算法與對(duì)象本身解耦，從而避免上述問題？

多態(tài)性就要求指針必須可以指向多種類，不是一個(gè)確定的類，引用不可以。

模式定義

定義一系列算法，把它們一個(gè)個(gè)封裝起來，并且使它們可互相替換（變化）。該模式使得算法可獨(dú)立于使用它的客戶程序（穩(wěn)定）而變化（擴(kuò)展，子類化）。
——《設(shè)計(jì)模式》Gof

常見方式

構(gòu)建一個(gè)基類，多個(gè)子類。
構(gòu)建一個(gè)類，引用這個(gè)基類，并在函數(shù)中由其他參數(shù)決定使用哪個(gè)子類。
橫向的自由度。

結(jié)構(gòu)（Structure）

Context和Strategy穩(wěn)定
ConcreteStrategy變化

要點(diǎn)總結(jié)

• Strategy 及其子類為組件提供了一系列可重用的算法，從而可以使得類型在運(yùn)行時(shí)方便地根據(jù)需要在各個(gè)算法之間進(jìn)行切換。
• Strategy 模式提供了用條件判斷語句以外的另一種選擇，消除條件判斷語句，就是在解耦合。含有許多條判斷語句的代碼通常都需要Strategy模式。
• 如果Strategy 對(duì)象沒有實(shí)例變量，那么各個(gè)上下文可以共享同一個(gè)Strategy 對(duì)象，從而節(jié)省對(duì)象開銷。

Observer 觀察者模式

動(dòng)機(jī)（Motivation）

• 在軟件構(gòu)架過程中，我們需要為某些對(duì)象建立一種“通知依賴關(guān)系”——一個(gè)對(duì)象（目標(biāo)對(duì)象）的狀態(tài)發(fā)生改變，所有的依賴對(duì)象（觀察者對(duì)象）都將得到通知。如果這樣的依賴關(guān)系過于緊密，將使軟件不能很好地抵御變化。
  *使用面向?qū)ο蠹夹g(shù)，可以將這種依賴關(guān)系弱化，并形成一種穩(wěn)定的依賴關(guān)系。從而實(shí)現(xiàn)軟件體系結(jié)構(gòu)的松耦合。

多繼承可以是一個(gè)繼承基類，以及多個(gè)繼承接口

模式定義

定義對(duì)象間的一種一對(duì)多（變化）的依賴關(guān)系，以便當(dāng)一個(gè)對(duì)象（Subject）的狀態(tài)發(fā)生改變時(shí)，所有依賴于它的對(duì)象都得到通知并自動(dòng)更新。
——《設(shè)計(jì)模式》Gof

結(jié)構(gòu)（Structure）

Subject和Observer是穩(wěn)定的
ConcreteSubject和CencreteObserver是變化的

常見方法

構(gòu)建一個(gè)消息類，在基類中建立其List表，然后由其他對(duì)象獲取其狀態(tài)。

要點(diǎn)總結(jié)

• 使用面向?qū)ο蟮某橄螅琌bserver 模式使得我們可以獨(dú)立地改變目標(biāo)與觀察者，從而使二者之間的依賴關(guān)系達(dá)至松耦合。
• 目標(biāo)發(fā)送通知時(shí)，無需指定觀察者，通知（可以攜帶通知信息作為參數(shù)）會(huì)自動(dòng)傳播。
• 觀察者自己決定是否需要訂閱通知，目標(biāo)對(duì)象對(duì)此一無所知。
• Observer模式是基于事件的UI框架中非常常用的設(shè)計(jì)模式，也是MVC模式的一個(gè)重要組成部分。

這是一種非常常用的模式。

“單一職責(zé)”模式：

• 在軟件組件的設(shè)計(jì)中，如果職責(zé)劃分的不清晰，使用繼承得到的結(jié)果往往是隨著需求的變化，子類急劇膨脹，同時(shí)充斥著重復(fù)代碼，這時(shí)候的關(guān)鍵是劃清責(zé)任。
• 典型模式
  • Decorator
  • Bridge

Decorator 裝飾模式

動(dòng)機(jī)（Motivation）

• 在某些情況下我們可能會(huì)“過度地使用繼承來擴(kuò)展對(duì)象的功能”，由于繼承為類型引入的靜態(tài)特質(zhì)，使得這種擴(kuò)展方式缺乏靈活性；并且隨著子類的增多（擴(kuò)展功能的增多），各種子類的組合（擴(kuò)展功能的組合）會(huì)導(dǎo)致更多子類的膨脹。
• 如何使“對(duì)象功能的擴(kuò)展”能夠根據(jù)需要來動(dòng)態(tài)地實(shí)現(xiàn)？同時(shí)避免“擴(kuò)展功能的增多”帶來的子類膨脹問題？從而使得任何“功能擴(kuò)展變化”所導(dǎo)致的影響降為最低？

一般結(jié)構(gòu)

裝飾結(jié)構(gòu)

組合優(yōu)于繼承

NetworkStream::Read(number);//繼承實(shí)現(xiàn)，靜態(tài)特質(zhì)
stream->Read(number);//組合實(shí)現(xiàn)，動(dòng)態(tài)特質(zhì)，可以改變
···
### 模式定義
動(dòng)態(tài)（組合）地給一個(gè)對(duì)象增加一些額外的職責(zé)。就增加功能而言，Decorator模式比生成子類（繼承）更為靈活（消除重復(fù)代碼&減少子類個(gè)數(shù)）。
——《設(shè)計(jì)模式》GoF

![結(jié)構(gòu)（Structure）](http://upload-images.jianshu.io/upload_images/4119448-9f6b4cceeffe7984.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

Component Decorator 穩(wěn)定
ConcreteConment ConcreteDecorator 變化

### 要點(diǎn)總結(jié)
* 通過采用組合而非繼承的首發(fā)，Decorator模式實(shí)現(xiàn)了在運(yùn)行時(shí)動(dòng)態(tài)擴(kuò)展對(duì)象功能的能力，而且可以根據(jù)需要擴(kuò)展多個(gè)功能。避免了使用繼承帶來的“靈活性差”和“多子類衍生問題”。
*  Decorator類在接口上表現(xiàn)為is-a Component的繼承關(guān)系，即Decorator類繼承了Component類所具有的接口。但在實(shí)際上又表現(xiàn)為has-a Component的組合關(guān)系，即Decorator類又使用了另外一個(gè)Component類。
* Decorator 模式的目的并非解決“多子類衍生的多繼承”問題，Decorator模式應(yīng)用的要點(diǎn)在于解決“主體類在多個(gè)方向上的擴(kuò)展功能”——是為“裝飾”的含義。

## Bridge 橋模式
### 動(dòng)機(jī)（Motivation）
* 由于某些類型的固有的實(shí)現(xiàn)邏輯，使得他們具有兩個(gè)變化的維度，乃至多個(gè)維度的變化。
* 如何應(yīng)對(duì)這種“多個(gè)維度的變化”？如何利用面向?qū)ο蠹夹g(shù)來使得類型可以輕松地沿著兩個(gè)乃至多個(gè)方向變化，而不引入額外的復(fù)雜度？

### 模式定義
將抽象部分（業(yè)務(wù)功能）與實(shí)現(xiàn)部分（平臺(tái)實(shí)現(xiàn)）分離，使它們都可以獨(dú)立地變化。
——《設(shè)計(jì)模式》 GoF

![結(jié)構(gòu)（Structure）](http://upload-images.jianshu.io/upload_images/4119448-57b1fd891e09c501.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
Abstraction Implementor 穩(wěn)定
RefinedAbstraction ConcreteImplementor 變化

### 要點(diǎn)總結(jié)
* Bridge模式使用“對(duì)象間的組合關(guān)系”解耦了抽象和實(shí)現(xiàn)之間固有的綁定關(guān)系，使得抽象和實(shí)現(xiàn)可以沿著各自的維度來變化。所謂抽象和實(shí)現(xiàn)沿著各自的維度的變化，即“子類化”它們。
* Bridge模式有時(shí)候類似于多繼承方案，但是多繼承方案往往違背單一職責(zé)原則（即一個(gè)類只有一個(gè)變化的原因），復(fù)用性比較差。Bridge模式是比多繼承方案更好的解決方法。
* Bridge模式的應(yīng)用一般在“兩個(gè)非常強(qiáng)的變化維度”，有時(shí)一個(gè)類也有多于兩個(gè)的變化維度，這時(shí)可以使用Bridge的擴(kuò)展模式。