概 要:在软件系统中,有时候我们会使用继承来扩展对象的功能,但是由于继承为类型引入的静态特质,使得这种扩展方式缺乏灵活性;
并且随着子类的增多(扩展功能的增多),各种子类的组合(扩展功能的组合)会导致更多子类的膨胀。如何使“对象功能的扩展”
能够根据需要来动态地实现?同时避免“扩展功能的增多”带来的子类膨胀问题?从而使得任何“功能扩展变化”所导致的影响
降为最低?
定 义:动态地给一个对象添加一些额外的职责。就增加功能来说,Decorator模式相比生成子类更为灵活
优 点:
1、装饰类和被装饰类可以独立发展,而不会相互耦合
2、装饰模型是继承关系的一个替代方案
3、装饰模型可以动态地扩展一个实现类的功能
缺 点:但是要避免多层装饰
使用场景:
1、需要扩展一个类的功能,或给一个类增加附加责任。
2、需要动态地给一个对象增加功能,这些功能可以再动态地撤销。
3、需要为一批的兄弟类进行改装或加装功能,当然是首选装饰模式
具体分析:
装饰类感觉与代理类在UML图上有些类似,但是其实质不一样,先来看看UML图:
Decorator模式采用对象组合而非继承的手法,实现了在运行时动态的扩展对象功能的能力,而且可以根据需要扩展多个功能,避免了单独使用继承带来的“灵活性差”和“多子类衍生问题”。同时它很好地符合面向对象设计原则中“优先使用对象组合而非继承”和“开放-封闭”原则。来看一个例子,小时候考试,回家需要让家长签字,那么这个时候如果成绩考的很差,很定要挨打,那么想个办法对成绩单进行一些扩充,让自己不再挨打呢?如果去直接修改成绩单,那很定是不行的,明眼人都能看出来,而且那个时候制作假证的水平不高,很定会露馅,下面能够解决实际问题的UML的图如下: