您的位置:首页 > 其它

大话设计模式----装饰模式

2017-10-25 14:17 211 查看
装饰模式:动态地给一个对象添加一些额外的职责,就增加功能来说,装饰模式比生成子类更为灵活。

装饰模式的UML类图:



Component是定义一个对象接口,可以给这些对象动态的添加职责。ConcreteComponent是定义了一个具体的对象,也可以给这个对象添加一些职责。Decorator,装饰抽象类,继承了Component,从外类来扩展Component类的功能,但对于Component来说,是无需知道Decorator的存在的。至于ConcreteDecorator就是具体的装饰对象,起到给Component添加职责的功能。

其实,装饰模式是利用SetComponent来对对象进行包装的,这样每个装饰的对象的实现就和如何使用这个对象分离开了,每个装饰对象只关心自己的功能,不需要关心如何能被添加到对象链当中。

我们学习模式也要学会变通,如果只有一个ConcreteComponent类而没有抽象的Component类,那么Decorator类可以是ConcreteComponent的一个子类。同样道理,如果只有一个ConcreteDecorator类,那么就没有必要建立一个单独的Decorator类,而可以把Decorator和ConcreteDecorator的责任合并成一个类。

装饰模式是为已有功能动态的添加更多功能的一种方式,那么我们什么时候用呢?

当系统需要新功能的时候,是向旧的类中添加新的代码。这些新的代码通常装饰了原有的类的核心职责或者主要行为。但这种做法的问题在于,它们在主类中加入了新的字段,新的方法和新的逻辑,从而增加了主类的复杂度,而这些新加入的东西仅仅是为了满足一些只在某种特定情况下才会执行的特殊行为的需要。而装饰模式提供了一个非常好的解决方案,他把每个要装饰的功能放在单独的类中,并让这个类包装她所要装饰的对象,因此,当需要执行特殊行为时,客户代码就可以在运行时根据需要有选择的,按顺序的使用装饰的对象了。

那么你总结出装饰模式的优点了吗?

这个模式把类中的装饰功能从类中搬移出去除,这样可以简化原有的类。

在用这个模式的时候,一定要记得装饰模式的装饰循序很重要!!!
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: