关于装饰(Decorator)模式的一个问题

[slg_sparkler]

大家对装饰模式了解么？看了这个模式后有点模糊，请明白人指教！
我对装饰模式的理解：
具体装饰角色通过抽象接口和具体构件角色形成关联，具体装饰角色通过修改和扩展具体构件角色的行为来达到对具体构件角色的扩展！ 感觉这个和继承差不多阿，那为什么装饰模式更好呢？

我看一本书上说：装饰模式允许系统动态地决定增加一个需要的装饰或者去掉一个不需要的装饰，而继承却不能，何以理解？

[usherlight]

模式和继承本来就不是一个概念啊。
一个语言的特性，一个编程的方式方法。

[zzhzzh204553]

class A{
void eat();
}

class DA{
A a;
void eat(){
//吃饭先 洗手．
洗手．
a.eat();　　
}

}

这样你就很容易决定，
要在吃饭前和吃饭后要做些什么．

[killme2008]

JAVA的io库就是最好的例子呐

[synico]

书上不是说了么，继承是静态的关系，在编译器就决定了。也就是说当你extends一个class的时候他们俩的关系就确定了。而使用装饰模式可以在运行期决定class之间的关系，为class增加新的方法，功能。我想就是一个用extends而一个不用，装饰模式使用了点手段达到了服用。打个比方人是个class继承自creature,那么人和creature的关系自人诞生起就决定了，呵呵，这个比方有点不是很恰当哈，如果给人加上好人这个装饰，他就是好人了，如果加坏人装饰，他就是坏人了。可以看出来决定一个人的好坏，不是天生的，这正应证了“人之初，性本善”。而是由外界环境决定，此时外界环境就相当于装饰了。解释不正之处请指正。

[zhaoliangsuper]

使用装饰模式是为了不用产生太多的类,但是它会产生很多的对象,java的IO里面就有好多的装饰模式,譬如说你要实现一个东西,用到了三个东西,这些东西都是继承于同一个类,其中有两个部分需要动态的变化的这个时候用装饰模式就不错,你可以再看看模版模式应该就会理解的更多了

[GODProbe]

使用装饰模式是为了不用产生太多的类——这个有道理。
有时候感觉装饰模式像一个方法组装器，又类似于门面（对象方法组装器）
讨论模式应该结合具体应用情况，有时候应用业务逻辑的建模不适合用继承关系，又符合装饰模式的前提（层层封装、互相解耦），那才是装饰模式的地方。
其实TMD说白了单独看装饰、门面、代理...这些模式有什么区别啊，都差不多！

[yun15291li]

我也觉得IO没学好。

[czlc]

对于功能A,B,C，具体构件角色D来说。
要实现为D添加A,B,C3个功能，必须继承3层，而且如果只有一个继承体系的话，它的顺序也就固定了，(A->B->C->D)。
而使用装饰模式可以动态new(A(new B(C)))包裹多层，任意组合。

[weimenren]

看书的时间认真一点,使用的时间仔细一点

Composite versus Decorator versus Proxy

Composite (163) and Decorator (175) have similar structure diagrams, reflecting the fact that both rely on recursive composition to organize an open-ended number of objects. This commonality might tempt you to think of a decorator object as a degenerate composite, but that misses the point of the Decorator pattern. The similarity ends at recursive composition, again because of differing intents.

Decorator is designed to let you add responsibilities to objects without subclassing. It avoids the explosion of subclasses that can arise from trying to cover every combination of responsibilities statically. Composite has a different intent. It focuses on structuring classes so that many related objects can be treated uniformly, and multiple objects can be treated as one. Its focus is not on embellishment but on representation.

These intents are distinct but complementary. Consequently, the Composite and Decorator patterns are often used in concert. Both lead to the kind of design in which you can build applications just by plugging objects together without defining any new classes. There will be an abstract class with some subclasses that are composites, some that are decorators, and some that implement the fundamental building blocks of the system. In this case, both composites and decorators will have a common interface. From the point of view of the Decorator pattern, a composite is a ConcreteComponent. From the point of view of the Composite pattern, a decorator is a Leaf. Of course, they don't have to be used together and, as we have seen, their intents are quite different.

Another pattern with a structure similar to Decorator's is Proxy (207). Both patterns describe how to provide a level of indirection to an object, and the implementations of both the proxy and decorator object keep a reference to another object to which they forward requests. Once again, however, they are intended for different purposes.

Like Decorator, the Proxy pattern composes an object and provides an identical interface to clients. Unlike Decorator, the Proxy pattern is not concerned with attaching or detaching properties dynamically, and it's not designed for recursive composition. Its intent is to provide a stand-in for a subject when it's inconvenient or undesirable to access the subject directly because, for example, it lives on a remote machine, has restricted access, or is persistent.

In the Proxy pattern, the subject defines the key functionality, and the proxy provides (or refuses) access to it. In Decorator, the component provides only part of the functionality, and one or more decorators furnish the rest. Decorator addresses the situation where an object's total functionality can't be determined at compile time, at least not conveniently. That open-endedness makes recursive composition an essential part of Decorator. That isn't the case in Proxy, because Proxy focuses on one relationship—between the proxy and its subject—and that relationship can be expressed statically.

These differences are significant because they capture solutions to specific recurring problems in object-oriented design. But that doesn't mean these patterns can't be combined. You might envision a proxy-decorator that adds functionality to a proxy, or a decorator-proxy that embellishes a remote object. Although such hybrids might be useful (we don't have real examples handy), they are divisible into patterns that are useful.