原文：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方法，而是構造函數的話，裝飾器模式就表現的更明顯了