我假设看这篇文章的朋友对装饰者模式都能有各自的、深入的理解。因为这篇文章是讨论装饰者模式的性能问题。 在本人的“.NET简谈设计模式之(装饰者模式)”一文中比较详细的讲解了装饰者模式的一般应用，但是我总是感觉装饰者模式隐隐约约之中有点不完美。经过我昨天一整天的思考、推敲终于找到了它隐隐约约中的那点不完美是什么，为了行为去继承带来的无辜的性能开销。所以本人想把它写出来，跟大家

装饰者模式其实有点难以理解，特别是对初学者来说可能有点晕，因为它的概念互相冲突，哪里互相冲突我们下面会讲解到。 本人保持一贯的写作风格，重在入门。在本人的这篇文章中会用一个比较恰当的比喻来让我们对问题迎刃而解，例子虽然简单但是重点突出。 在写这篇文章之前我在网上大概搜了一下关于“装饰者模式”的一些文章，但是讲解的效果都不太理想。要么就是找书搬过来的，要么就是对着书的例子从新

一、例子在软件开发中，我们往往会想要给某一类对象增加不同的功能。比如要给汽车增加ESP、天窗或者定速巡航。如果利用继承来实现，就需要定义无数的类，Car，ESPCar，CCSCar，SunRoofCar，ESPCCSCar……很容易就导致“子类爆炸”问题。上述“子类爆炸”问题的根源在于该解决方案利用继承来扩展功能，缺乏灵活

Wrapper模式的实现 作为.net framework 3.5 sp1 新添加的一个程序集，System.Web.Abstractions里所有的类，都是Wrapper/Decorator模式的。（System.Web.Abstractions里的类可以参见后面的附录，System.Web.Abstractions其实也早早出现在了Asp.net Mvc中）   在这里，所有的Wra