2011年(109)
分类: 系统运维
2011-07-21 16:58:56
装饰模式(Decorator)也叫包装器模式(Wrapper)。GOF 在《设计模式》一书中给出
的定义为:动态地给一个对象添加一些额外的职责。就增加功能来说,Decorator 模式相比
生成子类更为灵活。
让我们来理解一下这句话。我们来设计“ 门”这个类。假设你根据需求为“ 门”类作了如下
定义:
Door
open()
close()
lock()
现在,在系统的一个地方需要一个能够报警的Door,你来怎么做呢?你或许写一个Door
的子类AlarmDoor,在里面添加一个子类独有的方法alarm()。嗯,那在使用警报门的地方
你必须让客户知道使用的是警报门,不然无法使用这个独有的方法。而且,这个还违反了
Liskov 替换原则。
也许你要说,那就把这个方法添加到Door 里面,这样不就统一了?但是这样所有的门
都必须有警报,至少是个“哑巴”警报。而当你的系统仅仅在一两个地方使用了警报门,这明
显是不合理的——虽然可以使用缺省适配器来弥补一下。
这时候,你可以考虑采用装饰模式来给门动态的添加些额外的功能。
下面我们来看看装饰模式的组成,不要急着去解决上面的问题,到了下面自然就明白了!
1) 抽象构件角色(Component):定义一个抽象接口,以规范准备接收附加责任的对象。
2) 具体构件角色(Concrete Component ):这是被装饰者,定义一个将要被装饰增加功能的
类。
3) 装饰角色(Decorator):持有一个构件对象的实例,并定义了抽象构件定义的接口。
4) 具体装饰角色(Concrete Decorator):负责给构件添加增加的功能。