设计模式利剑11-装饰模式

 

概      要:在软件系统中,有时候我们会使用继承来扩展对象的功能,但是由于继承为类型引入的静态特质,使得这种扩展方式缺乏灵活性;

               并且随着子类的增多(扩展功能的增多),各种子类的组合(扩展功能的组合)会导致更多子类的膨胀。如何使“对象功能的扩展”

               能够根据需要来动态地实现?同时避免“扩展功能的增多”带来的子类膨胀问题?从而使得任何“功能扩展变化”所导致的影响

               降为最低?

定    义:动态地给一个对象添加一些额外的职责。就增加功能来说,Decorator模式相比生成子类更为灵活

优    点:

             1、装饰类和被装饰类可以独立发展,而不会相互耦合

             2、装饰模型是继承关系的一个替代方案

             3、装饰模型可以动态地扩展一个实现类的功能

缺      点:但是要避免多层装饰

使用场景:

              1、需要扩展一个类的功能,或给一个类增加附加责任。

              2、需要动态地给一个对象增加功能,这些功能可以再动态地撤销。

              3、需要为一批的兄弟类进行改装或加装功能,当然是首选装饰模式

具体分析:

              装饰类感觉与代理类在UML图上有些类似,但是其实质不一样,先来看看UML图:

image

       Decorator模式采用对象组合而非继承的手法,实现了在运行时动态的扩展对象功能的能力,而且可以根据需要扩展多个功能,避免了单独使用继承带来的“灵活性差”和“多子类衍生问题”。同时它很好地符合面向对象设计原则中“优先使用对象组合而非继承”和“开放-封闭”原则。来看一个例子,小时候考试,回家需要让家长签字,那么这个时候如果成绩考的很差,很定要挨打,那么想个办法对成绩单进行一些扩充,让自己不再挨打呢?如果去直接修改成绩单,那很定是不行的,明眼人都能看出来,而且那个时候制作假证的水平不高,很定会露馅,下面能够解决实际问题的UML的图如下:

image

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值