C C 知識點設計模式

在軟體工程中，設計模式用來描述在各種不同情況下，要怎麼解決問題的一種方案。物件導向設計模式通常以類或物件來描述其中的關係和相互作用，是軟體「設計」層次上的問題。使用設計模式可提高**的重用性和可靠性，使**更容易被他人理解，使**編制真正工程化。

一般將設計模式分為三種型別，共23種：

1.建立型模式

抽象工廠模式(abstract factory)：為乙個產品族提供一系列相關或相互依賴物件的介面，當需要該產品族某一系列時，可以從抽象工程中選出相應的系列建立乙個具體的工程類。

工廠模式(factory method)：定義乙個介面用於建立物件，讓子類決定將哪乙個類例項化，即把乙個類得例項化延遲到其子類。

單例模式(singleton)：確保乙個類僅有乙個例項，並提供對該例項的全域性訪問點。

原型模式(prototype)：用原型例項指定建立物件的種類，並且通過拷貝這些原型建立新的物件。

建造者模式(builder)：將乙個複雜物件的「構建」與「表示」分離，使得同樣的構建過程可以建立不同的表示。

2.結構型模式

**模式(proxy)：為其他物件提供乙個**，以控制對該物件的訪問。

介面卡模式(adapter)：將某個類的介面轉換成客戶端需要的另一種介面表示，使得原來介面不匹配的那些類達到相容效果。

橋接模式(bridge)：將抽象部分和它的實現部分分離，以便兩者可以獨立地變化。

組合模式(composite)：將物件組合成樹形結構以表示「部分-整體」的層次結構，這樣使得使用者可以統一對待單個物件和復合物件。

裝飾模式(decorator)：是除類繼承外的另一種擴充套件功能的方法，即動態地給某個物件新增一些額外的功能。

外觀模式(facade)：為子系統中的一組介面提供乙個一致的介面，facade模式定義了乙個高層介面，這個介面使得這一子系統更加容易使用。

享元模式(flyweight)：通過共享技術以有效地支援大量細粒度物件。

3.行為型模式

觀察者模式(observer)：在物件間定義一種一對多的依賴關係，以便當乙個物件改變狀態時，其他相關的物件會被通知並自動重新整理。

策略模式(strategy)：定義一系列演算法，將它們各自封裝，並使它們之間存在互動性。strategy模式使得演算法在使用者使用時能獨立地改變。

模版方法模式(template method)：構建乙個頂級邏輯框架，而將邏輯的細節延遲到具體子類中去實現。即準備乙個抽象類，將部分邏輯以具體方法及具體構建子類的形式實現，然後宣告一些抽象方法迫使子類實現剩餘的邏輯，這樣不同的子類可以以不同的方式實現這些抽象方法，從而對剩餘的邏輯有不同的實現。

迭代器模式(iterator)：提供一種方法順序訪問乙個聚合物件中各個元素，而又不需要暴露改物件的內部表示。

訪問者模式(visitor)：封裝一些施加於某種資料結構元素之上的操作。這樣在不改變各元素類的前提下，可對這些元素實現新的操作。visitor模式適用於資料結構相對未定的系統，它把資料結構和作用於資料結構上的操作之間的耦合解脫開，使得操作集合可以相對自由地演化。

命令模式(command)：將乙個請求封裝為乙個物件，從而使你可用不同的請求對客戶進行引數化；對請求排隊或記錄請求日誌，以及支援可取消的操作。

狀態模式(state)：允許乙個物件在其內部狀態改變時，其行為也隨之改變。state模式需要對每個系統可能獲取的狀態創立乙個狀態類的子類，當系統的狀態變化時，系統便改變所選的子類。

直譯器模式(interpreter)：給定一種語言，定義它的文法的一種表示，並定義乙個直譯器，該直譯器使用該表示來解釋語言中的句子。

中介者模式(mediator)：用乙個中介物件來封裝一系列的物件互動，使得這些物件不需顯示地相互引用，從而使其耦合鬆散。當某些物件之間的作用發生改變時，不會立即影響其他一些物件之間的作用，保證這些作用可以彼此獨立地變化。

職責鏈模式(chain of responsibility)：為解除請求的傳送者和接受者之間耦合，而使多個物件都有機會處理這個請求。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有乙個物件處理它。

備忘錄模式(memento)：在不破壞封裝性的前提下，捕獲乙個物件的內部狀態，並外部化儲存該狀態，從而以後可以將該物件恢復到儲存時的狀態。

C C 知識點 設計模式