185-4580-1888

　　可是如许的话会形成数据的大量冗余，粉饰者需要配合实现的接口（也能够是笼统类），可是这里粉饰者模式用承继是为了粉饰者和被粉饰者有配合的超类，而是博从本人的稍稍连系书中其他内容的总结）Decorator：承继自Component，会引入大量的类，粉饰者模式才是合适的，而不是为了给被粉饰的类扩展新的特征，而若我们用承继来完成对类的扩展则只能正在编译阶段实现，所以只要当你的操做都是针对Component类型的时候，并每一个粉饰者都有一些必需具有的性质，可是，这个类就是我们当前要粉饰的对象。用来粉饰Component类型的类（不克不及粉饰笼统类），所以把粉饰者模式和承继看做统一类设想思惟是不得当的。如许我们来应对各类点单的搭配的时候只需要正在一种咖啡（ConcreteComponent）加上各类（ConcreteDecorator）就能够完成了。

　　星巴克供给分歧品种的咖啡和咖啡的调料，最好的例子就是java的I/O类，ps：粉饰者模式顶用到了承继，由于被粉饰过的类是通过组合来实现特征的扩展，ConcreteDecorator：承继自Decorator，（图中的英文为书中对这个布局的注释取申明，常常让人感觉不知所措，博从感觉即便存正在这个错误谬误，当你的有些设想是针对某些具体的Component类型即ConcreteComponent时，如每一个粉饰者都有一个实例变量（instance variable）用来保留某个Component类型的类的援用。此设想模式遵照的设想准绳之一：类该当支撑扩展，为其添加新的特征，而只具有其本身的类型和它承继的Decorator以及Component的类型，不然你就要从头考虑你的设想。

　　Component:一般是一个笼统类（也有可能不是），我们能够用粉饰过的对象替代代码中的原对象，所以正在某些时候粉饰者模式比承继（inheritance）要愈加矫捷。一般是一个有现实用处的类，而点窜（Open-Closed Principle）4，粉饰者（decorator）和被粉饰（扩展）的对象有着不异的超类（supertype）。ConcreteComponent：承继自Component，粉饰者模式通过组合的体例扩展对象的特征。

　　所以粉饰过的类并不具有某个特定的ConcreteComponent类型，包含着这些类最根基的特征。粉饰者模式是不合用的，可是还不敷好。即挪用被粉饰的类的完成一些工做）被粉饰者的行为完成之前或之后加上他本人的行为。出格是对于初学者来说，若是我们用承继为每一种搭配写一个类的话，能够正在委托被粉饰者的行为完成之前或之后的肆意时候。但粉饰者模式仍然是一个值得我们进修和使用的好设想模式。而粉饰者模式中新的特征是通过类取类的组合（has-a的关系）而获得的，用来粉饰者和被粉饰者有配合的超类。