设计模式笔记(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和最初提到的虚函数重载，如此的神似呢，只不过目的和范围有所变化了。子类化不具备扩展性，一个排生类只能修饰一个基类，而模版恰好弥补了这一点。