設計模式筆記(5 COMPOSITE & DECORATOR)

COMPOSITE(組合)
適用性：
1.想表示對象的部分整體層次結構
2.希望用戶忽略組合對象和單個對象的不同。

思考：
組合模式的所有組件應該具備同一個接口。一直感覺，這種組合是一種遞歸組合的概念。所有的組件，按照樹的結構組織起來，樹的葉結點行爲可能和中間結點的行爲並不一致，這看上去違背了Liskov原則，似乎是一個容易引起迷惑的地方。
樹的葉結點可能並不能增加子結點，刪除子結點的行爲也可能失敗。而一箇中間結點則可能不具備一些葉結點才具備的具體功能。用戶需要在這兩者之間平衡。
我對COMPOSITE的理解可以概括成組件的遞歸組合。這個概括過於簡短，我不確定是否確實抓住了這個模式的本質，還是我過於缺乏理解。如果我的理解沒有問題的話，那麼，GUI系統的嵌套窗口對象可算是典型的COMPOSITE模式了。

DECORATOR（裝飾）
適用性：
1.在不影響其他同類對象的情況下，給某個對象透明的增加一些額外的功能。

思考：
考慮重載某個虛方法，並且，在這個方法中調用父類的重載方法。派生類的方法對父類的方法進行了“修飾”。這種方法依賴於類的派生。
考慮一個接口A，和實現了該接口的一系列的類，以及實例。現在，有一個裝飾類，也實現了接口A，並且，持有一個到其他實例的指針：
Interface A；
class Decorator : public A{
A * instance;
//實現接口A，在相關方法中調用instance的同名方法。
}；
我們看到，只要在Decorator實現的A接口的方法中，在調用instance的同名方法前後增加一些功能，就可以起到改變instance行爲的效果。
和Strategy的區別在於：Strategy是一種有擾的設計，要求設計的類本身具備策略調整能力。而Decorator並不要求設計類時考慮支持Decorator。
前面討論的都是爲對象增強能力，屬於動態範圍。其實，在GP橫行今天，C++中完全有了作用在靜態類型上的Decorator模式的可能。當然，這種模式不需要修飾類和被修飾類之間具備相同的Interface，而是修飾某個Concept了：
template<typename T>
struct Decorator : T
{
  void foo(){
    ...
    T::foo();
    ...
    }
};
避免了大量的子類化T。而且，這個Decorator和最初提到的虛函數重載，如此的神似呢，只不過目的和範圍有所變化了。子類化不具備擴展性，一個排生類只能修飾一個基類，而模版恰好彌補了這一點。