"Decorator模式的真正的威力在于对于一个被装饰(被油漆)的Decoratee提供多个Decorator的时候,也就是说,有多个额外的功能要被动态的刷到Decoratee中去,而这些功能在编译阶段并不能确定要具体增加那一些,而且增加的这些功能还有可能通过不同的组合完成不同的功能,这个时候使用Decorator模式的优势就很大了."被装卸的功能多了,很可能就变成灾难了。如果A a = new Decorator1 ( new Decorator2() );是可以接受的话,那么A a = new Decorator1 ( new Decorator2(new Decorator3(new Decorator4(new Decorator5(new Decorator6(new Decorator7()))))) );的感觉如何。
并且,实际使用中,并不是new Decorator1,2,3这种规则排列,而是一堆名字相似的CLASS互为构造器的入参。想体念这种感觉,写一个特别复杂的JAVA IO就可以体念到了。个人认为,这种代码难写难读,也就谈不上好维护了。
本质上,Decorator通过继承增加功能,当功能组合特别复杂时,n层的继承就不可避免了。这种情况下,倒不如增加一个组合上述功能的代理类,感觉更好一些。这样,就用n个类的组合代替了n层的继承。接口也不会发生变化。
纯Decorator模式,只合适用在增加2-4个功能的情况吧.