23種設計模式 - 結構型

標籤：des   cWeb   blog   http   io   os   使用   java   ar   

Bridge模式

UML圖：

解決的問題：bridge模式完成了抽象和實現部分的分離。兩邊變化互相不影響，提高了模組的內聚性。

原理：利用多態性，Abstraction類中包含AbstractionImp類的引用。

Adapter模式：

UML圖

解決的問題：開發過程中有時會使用第三方庫，但本身程式的介面已經設計好，且和第三方庫是不相容的。 此時可以利用適配器模式，從本身程式繼承介面，並代理到第三方程式具體實現

原理： Adapter繼承自介面Target類，並且Adapter中包含Adptee的指標對象。target的request()實際由Adaptee的SpecificRequest（）實現。

注意：介面類（target）與第三方類（Adptee）具有不同的介面名稱（request()和SpecificRequest（））

Decorator模式：

UML圖

解決的問題：開發中通常會發生要給已知的類天劍新功能，一般的做法是我們直接在原類的基礎上派生子類，這種方式可能導致類的深度過大，導致程式的可讀性降低。而裝飾器模式可以很好的解決這個問題，我們不需要在為類一層一層的派生子類，而是通過實現不同的ConcreteDecorator子類來完成新功能的添加。

原理：ConcreteComponent（待裝飾的類）和Decorator（裝飾父類）都繼承自component類並擁有同樣的基準Operation(),Decorator類中包含有component對象的指標（指向ConcreteComponent）。 而ConcreteDecoratorlei類中的operation會首先調用基準對象的operation（），然後可以添加新的功能AddBehavior（）.

Composite模式

UML圖

解決的問題： Composite模式很好地解決了將一個對象完成樹狀（或其他資料結構）形式的構建。

原理：Composite和Leaf均派生自介面Component， 在Composite類中完成Leaf對象的結構組織（例如樹狀，vector，list），Composite的operation類調用Leaf對象的operation完成具體對象的操作。

FlyWeight 模式

UML圖

解決的問題：當程式要建立大量具有相同特徵的“小對象”時，會造成記憶體的浪費。享元模式就是為瞭解決這個問題，在FlyWeight中包含有對象的緩衝池，根據需要給client提供共用對象。

Facade模式

UML圖

解決的問題：在開發中某一介面的實現可能分散在不同的類中，而該介面的使用者實際不需要瞭解實現的細節子類，此時可以通過Facade模式屏蔽具體的實現。

原理： Facade類中定義OperationWrapper方法，並包含具體實作類別SubSystem1和SubSystem2的指標對象。在OperationWrapper()中調用Subsystem1和Subsystem2中的Operation（）具體實現操作，從而屏蔽具體對象SubSystem1和SubSystem2.

Proxy模式

UML圖

解決的問題：解決某些效能或者許可權控制等問題時，可以將具體操作交給代理完成。（需進一步理解！！！）

23種設計模式 - 結構型