更高级的装饰器模式=》Archetype模式 （转帖+理解）

原文：http://www.cnblogs.com/west-link/archive/2011/06/16/2082422.html

 

下面是我对archetype模式的理解，也是对原blog的评论：

仔细看了一遍，给我的感觉是Archetype应该是在装饰器模式的基础上演化出来的一个模式，但没有脱离装饰器模式的本质，打个比方：如果说装饰器模式是父类，那么Archetype就是子类，父类比较泛化，适应的场景广泛；子类比较特化，适应场景少了，但更有针对性。
如果使用Gof中的装饰器模式做设计，根本不会有EventRecorderDecortor和EventRecorderDelegate这两个中间层抽象类，4个实现类2个逻辑处理类外加一个抽象接口，搞定！实现类和逻辑处理类都实现抽象接口。
不过这样的设计有如下的缺点或者说限制：
1：6个实现类分为2个逻辑部分，其中实现记录方式的4个类是不能用来修饰其他类的；
2：2个逻辑处理类之间是不能互相装饰的；
在不使用Archetype模式的情况下，上面的2个限制只能存在于程序员的脑子里或者文档中，子类间的分组没有通过代码表现出来
而Archetype模式通过引入EventRecorderDecortor和EventRecorderDelegate这2个中间抽象类完美的解决了上面的缺点，而且代码就是文档这种思想也表现出来了。
在我看来，Archetype模式对装饰器模式最大的贡献是在于通过加入中间抽象类将子类分为了不同的逻辑组，并利用这些中间抽象类限制了装饰的顺序（注意EventRecorderDecortor中的setDelegate方法），如果将Archetype模式仅限于业务处理逻辑和具体实现分离这个场景，反而限制了Archetype模式更大范围场景的应用。

PS：如果EventRecorderDecortor不用setDelegate方法，而是构造函数的话，装饰器模式就表现的更明显了