精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (6)
|
|
---|---|
作者 | 正文 |
发表时间:2010-02-09
最后修改:2010-02-09
标头:(引自设计模式) 为了扩展代码库,通常给它添加新类或者新方法。有时候,你也许不希望在运行时候使用新行为来组合对象。Interpreter模式允许你组合可执行对象,这个对象的行为可能变化会非常快。在有些情况下,你也许需要行为上的小变化,并且希望能够把这些变化事例起来,decorator模式可以满足这个需求。
decorator的意图就是在运行时组合操作的新变化
以经典例子IO流为例: java类库里输入/输出流就是一个典型的decorator模式的例子,流是一系列比特或者字符的集合,比如文档中出现的字符集合。在java中,writer是支持流的一个方法,有些输出器(writer)类的构造器的参数可以是其他输出器,这样可以基于其他输出器来创建输出器.这种组合就是decorator模式的结构。 让我们来举个例子,看看如下代码,它创建一个小的文本文件: public class ShowDecorator { public static void main(String[] args) { try { FileWriter write = new FileWriter("c://test.txt"); BufferedWriter bw = new BufferedWriter(write); bw.write("hello,LGH ,my name is Liuguohua"); bw.close(); write.close(); } catch (Exception e) { // TODO Auto-generated catch block e.printStackTrace(); } } }
运行这个程序,我们会得到一个test.txt 文件,其中包含一部分示范文字,本程序使用FileWriter对象来创新新文件,把这个对象包容在BufferedWriter中。需要注意的一个地方是我们可以从一个流组合另一个流,这部分代码从某FileWriter对象组合得到一个BufferedWriter对象。
一个很平常的应用,我们想要对用户每次输入的数据或者想对一个文本数据进行过滤等,这个时候可以开发个过滤器集合,通过选择已经存在的writer类中的操作,可以创建继承自Writer类所有行为的一个类 下面的图展示了设计思路: 2)我们这里只假设需要对用户输入字母变成小写,所以重写了方法write(char[],off:int,len:int) 3)除了方法writer(:int)及write(char[],off:int,len:int),其它方法采用默认实现
SuperWriter:
public abstract class SuperWriter extends Writer{ protected Writer out; protected SuperWriter(Writer out){ super(out); this.out = out; } }
这部分代码比较简单,只是简单继承Writer. DecoratorWriter:
public abstract class DecoratorWriter extends SuperWriter{ public DecoratorWriter(Writer out){ super(out); } @Override public void write(String s){ char[] cs = s.toCharArray(); for(char cc:cs){ write(cc); } } public abstract void write(int c); @Override public void close() throws IOException { // TODO Auto-generated method stub out.close(); } @Override public void flush() throws IOException { // TODO Auto-generated method stub out.flush(); } @Override public void write(char[] cbuf, int off, int len) throws IOException { // TODO Auto-generated method stub for(int i =off;i<len;i++){ write(cbuf[i]); } } }
该类为抽象类,提供除wirte(:int)方法以后的默认实现,其子类必须实现write(:int),对数据进行相应的操作。 现在,我们可以容易的创建和使用新的装饰模式过滤器,比如,如下类的功能就是把所有的字母转换成小写形式: public class LowerCaseWriter extends DecoratorWriter{ public LowerCaseWriter(Writer out){ super(out); } @Override public void write(int c) { // TODO Auto-generated method stub try { out.write(Character.toLowerCase(c)); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } } public static void main(String[] args) { try { LowerCaseWriter caseWriter = new LowerCaseWriter(new FileWriter("c://hah.txt")); caseWriter.write("HELLO,LGH,hello lgh"); caseWriter.close(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } } } 程序会把文本“hello,lgh,hello lgh”,输出到文本里。 相应的我们可以写一个把所有字母转换成大写形式等等。
原因: 我们为什么要这样写呢,一个是复用,使代码看起来整洁一个就是功能多样化,如果只想在一个类里实现这些功能,不仅会使代码变得很庞大难以维护,同时如果想要每种类都有这种功能的话,我们必须通过继承的方式,否会只会作茧自缚.
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2010-02-09
通用性还可以
|
|
返回顶楼 | |
发表时间:2010-03-01
看下headfirst设计模式这书吧,很通俗易懂,说的比楼主的清晰多了
|
|
返回顶楼 | |
发表时间:2010-03-02
刃之舞 写道 看下headfirst设计模式这书吧,很通俗易懂,说的比楼主的清晰多了
当然headfirst出版的设计模式是本好书,但并不一定适合所有的读者。 |
|
返回顶楼 | |
发表时间:2010-03-02
行者买刀 写道 刃之舞 写道 看下headfirst设计模式这书吧,很通俗易懂,说的比楼主的清晰多了
当然headfirst出版的设计模式是本好书,但并不一定适合所有的读者。 如果连headfirst的书都看不懂,那也就还没到搞设计模式的火候,如果认为那本书讲的太浅显的,从你的说明中也不会得到什么。 |
|
返回顶楼 | |
发表时间:2010-03-02
最后修改:2010-03-02
刃之舞 写道 行者买刀 写道 刃之舞 写道 看下headfirst设计模式这书吧,很通俗易懂,说的比楼主的清晰多了
当然headfirst出版的设计模式是本好书,但并不一定适合所有的读者。 如果连headfirst的书都看不懂,那也就还没到搞设计模式的火候,如果认为那本书讲的太浅显的,从你的说明中也不会得到什么。 headfirst设计模式本书确实如你所述,很通俗易懂。 但就像 大家都喜欢听歌,大部分目的为了娱乐心情,但总不能说你喜欢听张三的歌,认为张三唱的境界最高,没听懂他的歌就达不到听歌的境界。没有听懂张三的歌,别的也不用听了。 ps:如果你对于设计模式你有更好的理解,可否分享一下。 再次,设计模式实乃个人之略见一斑,其深,其广,有待去从更多的实践中得到启发。 |
|
返回顶楼 | |
发表时间:2010-03-03
装饰器模式的精髓我觉得应该是排列组合。比如10=2*5。用户-角色-权限模型也是装饰器模式。LZ觉得呢?
|
|
返回顶楼 | |
发表时间:2010-03-03
piao_bo_yi 写道 装饰器模式的精髓我觉得应该是排列组合。比如10=2*5。用户-角色-权限模型也是装饰器模式。LZ觉得呢?
经常看到一个追MM装饰者模式,我觉得说的很好。 引用 说有一MM过生日,于是男朋友给他买了蛋糕,但总不能直接拿过去,蛋糕总要装饰一下才行。于是一个被包装的漂漂亮亮的蛋糕就出现了。这就是装饰模式了。 |
|
返回顶楼 | |
发表时间:2010-03-12
最后修改:2010-03-12
大部分模式来说,都有个一个根本的起点就是OCP,站在这个起点的角度上看才能比较清楚的理解模式为什么要存在。
装饰者模式,从定义上说就是 动态的把一个特殊的个性的责任放到一个对象上, 如果使用继承做也可以,但是数量级上去后必然会早成类爆炸,可变性也必然会影响OCP的初衷。 装饰者是巧妙的使用继承来来达到这个效果, 装饰者中使用继承不是为了扩展和附加责任,而是为了获取类型的一致即多态,这应该属于对继承的一个技巧性的使用 基类接口, 待包装类 装饰者接口 具体的装饰者 装饰者接口从基类继承后获取和待包装类的类型上的一致,然后具体的装饰者中使用组合(这边才正式应用了,多用组合少用继承的原则)组合待包装类,并将自身的责任或者行为包装给待包装类的具体的方法。 |
|
返回顶楼 | |
浏览 4421 次