設計模式之結構型模式

結構型模式描述如何將類或對象按某種布局組成更大的結構。它分為類結構型模式和對象結構型模式，前者采用繼承機制來組織接口和類，后者釆用組合或聚合來組合對象。

設計模式名稱

簡要說明

代理模式

（Proxy）

為某對象提供一種代理以控制對該對象的訪問。即客戶端通過代理間接地訪問該對象，從而限制、增強或修改該對象的一些特性。

適配器模式

（Adapter）

將一個類的接口轉換成客戶希望的另外一個接口，使得原本由于接口不兼容而不能一起工作的那些類能一起工作。

橋接模式

（Bridge）

將抽象與實現分離，使它們可以獨立變化。它是用組合關系代替繼承關系來實現的，從而降低了抽象和實現這兩個可變維度的耦合度。

裝飾模式

（Decorator）

動態地給對象增加一些職責，即增加其額外的功能。

外觀模式

（Facade）

為多個復雜的子系統提供一個一致的接口，使這些子系統更加容易被訪問。

享元模式

（Flyweight）

運用共享技術來有效地支持大量細粒度對象的復用。

組合模式

（Composite）

將對象組合成樹狀層次結構，使用戶對單個對象和組合對象具有一致的訪問性。

代理模式

1、概述：

代理模式的定義：由于某些原因需要給某對象提供一個代理以控制對該對象的訪問。這時，訪問對象不適合或者不能直接引用目標對象，代理對象作為訪問對象和目標對象之間的中介。

2、主要角色：

①、 Subject（抽象主題角色）：它聲明了真實主題和代理主題的共同接口，這樣一來在任何使用真實主題的地方都可以使用代理主題，客戶端通常需要針對抽象主題角色進行編程。

②、Proxy（代理主題角色）：它包含了對真實主題的引用，從而可以在任何時候操作真實主題對象；在代理主題角色中提供一個與真實主題角色相同的接口，以便在任何時候都可以替代真實主題；代理主題角色還可以控制對真實主題的使用，負責在需要的時候創建和刪除真實主題對象，并對真實主題對象的使用加以約束。通常，在代理主題角色中，客戶端在調用所引用的真實主題操作之前或之后還需要執行其他操作，而不僅僅是單純調用真實主題對象中的操作。

③、 RealSubject（真實主題角色）：它定義了代理角色所代表的真實對象，在真實主題角色中實現了真實的業務操作，客戶端可以通過代理主題角色間接調用真實主題角色中定義的操作。

3、應用場景：

①、當客戶端對象需要訪問遠程主機中的對象時可以使用遠程代理。

②、當需要用一個消耗資源較少的對象來代表一個消耗資源較多的對象，從而降低系統開銷、縮短運行時間時可以使用虛擬代理，例如一個對象需要很長時間才能完成加載時。

③、當需要為某一個被頻繁訪問的操作結果提供一個臨時存儲空間，以供多個客戶端共享訪問這些結果時可以使用緩沖代理。通過使用緩沖代理，系統無須在客戶端每一次訪問時都重新執行操作，只需直接從臨時緩沖區獲取操作結果即可。

④、當需要控制對一個對象的訪問，為不同用戶提供不同級別的訪問權限時可以使用保護代理。

⑤、當需要為一個對象的訪問（引用）提供一些額外的操作時可以使用智能引用代理。

4、優點：

①、能夠協調調用者和被調用者，在一定程度上降低了系統的耦合度。

②、客戶端可以針對抽象主題角色進行編程，增加和更換代理類無須修改源代碼，符合開閉原則，系統具有較好的靈活性和可擴展性。

5、缺點：

①、由于在客戶端和真實主題之間增加了代理對象，因此有些類型的代理模式可能會造成請求的處理速度變慢，例如保護代理。

②、實現代理模式需要額外的工作，而且有些代理模式的實現過程較為復雜，例如遠程代理。

適配器模式

1、概述：

適配器模式（Adapter）的定義如下：將一個類的接口轉換成客戶希望的另外一個接口，使得原本由于接口不兼容而不能一起工作的那些類能一起工作。適配器模式分為類結構型模式和對象結構型模式兩種，前者類之間的耦合度比后者高，且要求程序員了解現有組件庫中的相關組件的內部結構，所以應用相對較少些。

2、主要角色：

①、目標（Target）接口：當前系統業務所期待的接口，它可以是抽象類或接口。

②、適配者（Adaptee）類：它是被訪問和適配的現存組件庫中的組件接口。

③、適配器（Adapter）類：它是一個轉換器，通過繼承或引用適配者的對象，把適配者接口轉換成目標接口，讓客戶按目標接口的格式訪問適配者。

3、應用場景：

①、系統需要使用一些現有的類，而這些類的接口（如方法名）不符合系統的需要，甚至沒有這些類的源代碼。

②、想創建一個可以重復使用的類，用于與一些彼此之間沒有太大關聯的一些類，包括一些可能在將來引進的類一起工作。

4、優點：

①、客戶端通過適配器可以透明地調用目標接口。

②、復用了現存的類，程序員不需要修改原有代碼而重用現有的適配者類。

③、將目標類和適配者類解耦，解決了目標類和適配者類接口不一致的問題。

④、在很多業務場景中符合開閉原則。

5、缺點：

①、適配器編寫過程需要結合業務場景全面考慮，可能會增加系統的復雜性。

②、增加代碼閱讀難度，降低代碼可讀性，過多使用適配器會使系統代碼變得凌亂。

橋接模式

1、概述：

橋接（Bridge）模式的定義如下：將抽象與實現分離，使它們可以獨立變化。它是用組合關系代替繼承關系來實現，從而降低了抽象和實現這兩個可變維度的耦合度。

2、主要角色：

①、抽象化（Abstraction）角色：定義抽象類，并包含一個對實現化對象的引用。

②、擴展抽象化（Refined Abstraction）角色：是抽象化角色的子類，實現父類中的業務方法，并通過組合關系調用實現化角色中的業務方法。

③、實現化（Implementor）角色：定義實現化角色的接口，供擴展抽象化角色調用。

④、具體實現化（Concrete Implementor）角色：給出實現化角色接口的具體實現。

3、應用場景：

①、當一個類存在兩個獨立變化的維度，且這兩個維度都需要進行擴展時。

②、當一個系統不希望使用繼承或因為多層次繼承導致系統類的個數急劇增加時。

③、當一個系統需要在構件的抽象化角色和具體化角色之間增加更多的靈活性時。

4、優點：

①、抽象與實現分離，擴展能力強

②、符合開閉原則

③、符合合成復用原則

④、其實現細節對客戶透明

5、缺點：

由于聚合關系建立在抽象層，要求開發者針對抽象化進行設計與編程，能正確地識別出系統中兩個獨立變化的維度，這增加了系統的理解與設計難度。

裝飾模式

1、概述：

裝飾器（Decorator）模式的定義：指在不改變現有對象結構的情況下，動態地給該對象增加一些職責（即增加其額外功能）的模式，它屬于對象結構型模式。

2、主要角色：

①、抽象構件（Component）角色：定義一個抽象接口以規范準備接收附加責任的對象。

②、具體構件（ConcreteComponent）角色：實現抽象構件，通過裝飾角色為其添加一些職責。

③、抽象裝飾（Decorator）角色：繼承抽象構件，并包含具體構件的實例，可以通過其子類擴展具體構件的功能。

④、具體裝飾（ConcreteDecorator）角色：實現抽象裝飾的相關方法，并給具體構件對象添加附加的責任。

3、應用場景：

①、當需要給一個現有類添加附加職責，而又不能采用生成子類的方法進行擴充時。例如，該類被隱藏或者該類是終極類或者采用繼承方式會產生大量的子類。

②、當需要通過對現有的一組基本功能進行排列組合而產生非常多的功能時，采用繼承關系很難實現，而采用裝飾器模式卻很好實現。

③、當對象的功能要求可以動態地添加，也可以再動態地撤銷時。

4、優點：

①、裝飾器是繼承的有力補充，比繼承靈活，在不改變原有對象的情況下，動態的給一個對象擴展功能，即插即用

②、通過使用不用裝飾類及這些裝飾類的排列組合，可以實現不同效果

裝飾器模式完全遵守開閉原則

5、缺點：

裝飾器模式會增加許多子類，過度使用會增加程序得復雜性。

外觀模式

1、概述：

外觀（Facade）模式又叫作門面模式，是一種通過為多個復雜的子系統提供一個一致的接口，而使這些子系統更加容易被訪問的模式。該模式對外有一個統一接口，外部應用程序不用關心內部子系統的具體細節，這樣會大大降低應用程序的復雜度，提高了程序的可維護性。

2、主要角色：

①、外觀（Facade）角色：為多個子系統對外提供一個共同的接口。

②、子系統（Sub System）角色：實現系統的部分功能，客戶可以通過外觀角色訪問它。

③、客戶（Client）角色：通過一個外觀角色訪問各個子系統的功能。

3、應用場景：

①、對分層結構系統構建時，使用外觀模式定義子系統中每層的入口點可以簡化子系統之間的依賴關系。

②、當一個復雜系統的子系統很多時，外觀模式可以為系統設計一個簡單的接口供外界訪問。

③、當客戶端與多個子系統之間存在很大的聯系時，引入外觀模式可將它們分離，從而提高子系統的獨立性和可移植性。

4、優點：

①、降低了子系統與客戶端之間的耦合度，使得子系統的變化不會影響調用它的客戶類。

②、對客戶屏蔽了子系統組件，減少了客戶處理的對象數目，并使得子系統使用起來更加容易。

③、降低了大型軟件系統中的編譯依賴性，簡化了系統在不同平臺之間的移植過程，因為編譯一個子系統不會影響其他的子系統，也不會影響外觀對象。

5、缺點：

①、不能很好地限制客戶使用子系統類，很容易帶來未知風險。

②、增加新的子系統可能需要修改外觀類或客戶端的源代碼，違背了“開閉原則”。

享元模式

1、概述：

享元（Flyweight）模式的定義：運用共享技術來有效地支持大量細粒度對象的復用。它通過共享已經存在的對象來大幅度減少需要創建的對象數量、避免大量相似類的開銷，從而提高系統資源的利用率。

2、主要角色：

①、抽象享元角色（Flyweight）：是所有的具體享元類的基類，為具體享元規范需要實現的公共接口，非享元的外部狀態以參數的形式通過方法傳入。

②、具體享元（Concrete Flyweight）角色：實現抽象享元角色中所規定的接口。

非享元（Unsharable Flyweight)角色：是不可以共享的外部狀態，它以參數的形式注入具體享元的相關方法中。

③、享元工廠（Flyweight Factory）角色：負責創建和管理享元角色。當客戶對象請求一個享元對象時，享元工廠檢査系統中是否存在符合要求的享元對象，如果存在則提供給客戶；如果不存在的話，則創建一個新的享元對象。

3、應用場景：

①、系統中存在大量相同或相似的對象，這些對象耗費大量的內存資源。

②、大部分的對象可以按照內部狀態進行分組，且可將不同部分外部化，這樣每一個組只需保存一個內部狀態。

③、由于享元模式需要額外維護一個保存享元的數據結構，所以應當在有足夠多的享元實例時才值得使用享元模式。

4、優點：

相同對象只要保存一份，這降低了系統中對象的數量，從而降低了系統中細粒度對象給內存帶來的壓力。

5、缺點：

①、為了使對象可以共享，需要將一些不能共享的狀態外部化，這將增加程序的復雜性。

②、讀取享元模式的外部狀態會使得運行時間稍微變長。

組合模式

1、概述：

組合（Composite Pattern）模式的定義：有時又叫作整體-部分（Part-Whole）模式，它是一種將對象組合成樹狀的層次結構的模式，用來表示“整體-部分”的關系，使用戶對單個對象和組合對象具有一致的訪問性。

2、主要角色：

①、抽象構件（Component）角色：它的主要作用是為樹葉構件和樹枝構件聲明公共接口，并實現它們的默認行為。在透明式的組合模式中抽象構件還聲明訪問和管理子類的接口；在安全式的組合模式中不聲明訪問和管理子類的接口，管理工作由樹枝構件完成。（總的抽象類或接口，定義一些通用的方法，比如新增、刪除）

②、樹葉構件（Leaf）角色：是組合中的葉節點對象，它沒有子節點，用于繼承或實現抽象構件。

③、樹枝構件（Composite）角色 / 中間構件：是組合中的分支節點對象，它有子節點，用于繼承和實現抽象構件。它的主要作用是存儲和管理子部件，通常包含 Add()、Remove()、GetChild() 等方法。

3、應用場景：

①、在需要表示一個對象整體與部分的層次結構的場合。

②、要求對用戶隱藏組合對象與單個對象的不同，用戶可以用統一的接口使用組合結構中的所有對象的場合。

4、優點：

①、組合模式使得客戶端代碼可以一致地處理單個對象和組合對象，無須關心自己處理的是單個對象，還是組合對象，這簡化了客戶端代碼；

②、更容易在組合體內加入新的對象，客戶端不會因為加入了新的對象而更改源代碼，滿足“開閉原則”；

5、缺點：

①、設計較復雜，客戶端需要花更多時間理清類之間的層次關系；

不容易限制容器中的構件；

②、不容易用繼承的方法來增加構件的新功能。

設計模式之設計原則

設計模式之創建型模式

設計模式之行為型模式

開發者

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。