課堂做業06_23種設計模式

設計模式普遍用於面向對象的開發和設計中，成爲面向對象的重要組成部分。設計模式只在必定的抽象層次上討論模式。設計模式做爲一個專有名詞，特指在特定場景下解決通常設計問題的類和相互通訊的對象的描述。像鏈表、hash表這樣的設計，通常不稱做設計模式，而那些包括複雜的、特定領域內的對整個應用或子系統的架構的設計也不是設計模式所討論的範圍 。

設計模式的定義爲：設計模式是一種被反覆使用、多人知曉的、通過分類編目的、代碼設計經驗的總結，使用設計模式是爲了可重用代碼、讓代碼更容易被人理解、保證代碼的可靠性。設計模式是軟件工程的基石，如同大廈的一塊塊磚石同樣。設計模式於己於他人於系統都是多贏的，設計模式使代碼編制真正工程化。項目中合理的運用設計模式能夠完美的解決不少問題，每種模式在如今中都有相應的原理來與之對應，每個模式描述了一個在咱們周圍不斷重複發生的問題，以及該問題的核心解決方案，這也是它能被普遍應用的緣由。

設計模式根據目的可分爲：建立型、結構型、行爲型。建立型模式主要用於建立對象；結構型模式主要用於處理類和對象的組合；行爲型模式主要用於描述對類或對象怎麼交互和怎麼分配職責。

建立型模式：

1.簡單工廠

簡單工廠模式是由一個工廠對象決定建立出哪種產品類的實例。簡單工廠模式是工廠模式家族中最簡單實用的模式，能夠理解爲是不一樣工廠模式的一個特殊實現。

2.工廠方法模式

    是簡單工廠模式的延伸。工廠父類負責定義建立產品對象的公共接口，而子工廠負責具體生產具體的產品對象。所謂的決定並非批模式容許子類自己在運行時作決定，而是指在編寫建立者類時，不需知道建立的產品是哪一下，選擇了使用哪一個子類，就決定了實際建立的產品是什麼。

3.抽象工廠模式

在抽象工廠模式中，接口是負責建立一個相關對象的工廠，不須要顯式指定它們的類。每一個生成的工廠都能按照工廠模式提供對象。提供一個建立一系列相關或相互依賴對象的接口，而無需指定它們具體的類。主要解決接口選擇的問題。

4.建造者模式

將一個複雜的構建與其表示相分離，使得一樣的構建過程能夠建立不一樣的表示。主要解決：在軟件系統中，有時候面臨着"一個複雜對象"的建立工做，其一般由各個部分的子對象用必定的算法構成；因爲需求的變化，這個複雜對象的各個部分常常面臨着劇烈的變化，可是將它們組合在一塊兒的算法卻相對穩定。

5.原型模式

用原型實例指定建立對象的種類，而且經過複製這些原型建立新的對象。既能用於建立重複的對象，同時又能保證性能。主要解決：在運行期創建和刪除原型。

6.單例模式

    保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。主要解決：一個全局使用的類頻繁地建立與銷燬。這種模式涉及到一個單一的類，該類負責建立本身的對象，同時確保只有單個對象被建立。這個類提供了一種訪問其惟一的對象的方式，能夠直接訪問，不須要實例化該類的對象。

結構型模式

1.適配器模式

將一個接口轉化爲客戶但願的另外一個接口，適配器模式使接口不兼容的類一塊兒工做。是兩個不兼容類的橋樑。主要解決：在軟件系統中，經常要將一些"現存的對象"放到新的環境中，而新環境要求的接口是現對象不能知足的。

例如：加密模塊在此基礎上實如今不修改現有類的基礎上重用第三方加密方法。

2.橋接模式

將抽象部分與實現部分分離，使它們均可以獨立的變化。主要解決：在有多種可能會變化的狀況下，用繼承會形成類爆炸問題，擴展起來不靈活。

例如：跨平臺視屏播放器。

3.組合模式

組合多個對象造成樹形結構以表示「總體-部分」的結構層次。組合模式使得用戶對單個對象和組合對象的使用具備一致性。主要解決：它在咱們樹型結構的問題中，模糊了簡單元素和複雜元素的概念，客戶程序能夠向處理簡單元素同樣來處理複雜元素，從而使得客戶程序與複雜元素的內部結構解耦。

例如：文件夾的樹形結構訪問。

4.裝飾模式

動態地給一個對象添加一些額外的職責。就增長功能來講，裝飾器模式相比生成子類更爲靈活。主要解決：通常的，咱們爲了擴展一個類常用繼承方式實現，因爲繼承爲類引入靜態特徵，而且隨着擴展功能的增多，子類會很膨脹。

例如：在原有基礎上實現多重加密。

5.外觀模式

爲子系統中的一組接口提供一個一致的界面，外觀模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。主要解決：下降訪問複雜系統的內部子系統時的複雜度，簡化客戶端與之的接口。

例如：文件加密。加密的過程包括三個操做：讀取文件、加密、保存加密以後文件。

6.享元模式

運用共享技術有效地支持大量細粒度的對象。主要解決：在有大量對象時，有可能會形成內存溢出，咱們把其中共同的部分抽象出來，若是有相同的業務請求，直接返回在內存中已有的對象，避免從新建立。

7.代理模式

    爲其餘對象提供一種代理以控制對這個對象的訪問。主要解決：在直接訪問對象時帶來的問題。

行爲型模式

1.職責鏈模式

避免請求發送方與接收方耦合在一塊兒，讓多個對象均可以接收請求，將這些對象鏈接一條鏈，而且沿着這條鏈傳遞請求，直到有對象處理它爲止。主要解決：職責鏈上的處理者負責處理請求，客戶只須要將請求發送到職責鏈上便可，無須關心請求的處理細節和請求的傳遞，因此職責鏈將請求的發送者和請求的處理者解耦了。

例如：按級別進行請假處理。

2.命令模式

    將一個請求封裝成一個對象，從而使您能夠用不一樣的請求對客戶進行參數化。

主要解決：在軟件系統中，行爲請求者與行爲實現者一般是一種緊耦合的關係，但某些場合，好比須要對行爲進行記錄、撤銷或重作、事務等處理時，這種沒法抵禦變化的緊耦合的設計就不太合適。

    例如：撤銷操做的實現

3.解釋器模式

    給定一個語言，定義它的文法表示，並定義一個解釋器，這個解釋器使用該標識來解釋語言中的句子。主要解決：對於一些固定文法構建一個解釋句子的解釋器。

4.迭代器模式

提供了一種方法訪問聚合對象，而不用暴露這個對象的內部表示。主要解決：不一樣的方式來遍歷整個整合對象。主要解決：不一樣的方式來遍歷整個整合對象。

    例如：電視遙控器實現對電視頻道集合遍歷操做。

5.中介者模式

    中介者模式（Mediator Pattern）是用來下降多個對象和類之間的通訊複雜性。這種模式提供了一箇中介類，該類一般處理不一樣類之間的通訊，並支持鬆耦合，使代碼易於維護。中介者模式屬於行爲型模式。用一箇中介對象來封裝一系列的對象交互，中介者使各對象不須要顯式地相互引用，從而使其耦合鬆散，並且能夠獨立地改變它們之間的交互。主要解決：對象與對象之間存在大量的關聯關係，這樣勢必會致使系統的結構變得很複雜，同時若一個對象發生改變，咱們也須要跟蹤與之相關聯的對象，同時作出相應的處理。

6.備忘錄模式

    在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象以外保存這個狀態。主要解決：所謂備忘錄模式就是在不破壞封裝的前提下，捕獲一個對象的內部狀態，並在該對象以外保存這個狀態，這樣能夠在之後將對象恢復到原先保存的狀態。

7.觀察者模式

定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，全部依賴於它的對象都獲得通知並被自動更新。主要解決：一個對象狀態改變給其餘對象通知的問題，並且要考慮到易用和低耦合，保證高度的協做。

    例如：貓是老鼠和狗的觀察目標，老鼠和狗是觀察者，貓叫則老鼠跑，夠野跟着叫。

8.狀態模式

容許對象在內部狀態發生改變時改變它的行爲，對象看起來好像修改了它的類。

主要解決：對象的行爲依賴於它的狀態（屬性），而且能夠根據它的狀態改變而改變它的相關行爲。

9.策略模式

定義一系列的算法,把它們一個個封裝起來, 而且使它們可相互替換。主要解決：在有多種算法類似的狀況下，使用 if...else 所帶來的複雜和難以維護。

10.模板方法模式

定義一個操做中的算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類能夠不改變一個算法的結構便可重定義該算法的某些特定步驟。主要解決：一些方法通用，卻在每個子類都從新寫了這一方法。

11.訪問者模式

主要將數據結構與數據操做分離。主要解決：穩定的數據結構和易變的操做耦合問題。