xuesenlin http://www.jdon.com Oct 27, 2004 11:05 PM 
回复
最q这个段旉都是忙于学习(fn) SpringFrameworkQ那东东好样的，只是刚刚学完StrutsQHibernateQ有来了(jin)q个Q呵呵，Q感觉挺累的?BR>“你怎么把这两个不相q的东西撤到一P?Q确实是q样Q?无论从他们的设计Q?BR>实现Q用等斚w他们是风马牛不相?qing)?但本Z理解的方面看他们有点cM。况且学?fn)要从对比中学呀Q这对初学者会(x)有帮助于理解?BR>重要声明Q本人都是用自己的语a写的Q有专业术语不对q请大家指出? - ) ZT?
p设计模式 [b]Decorator[/b],也就是装饰模式，q还?sh)好理解Q?在原有的东西上进行装C下便是装C(jin)。既然是装饰Q你要有M呀Q被修饰的东西）(j)Q还要有装饰品。但是不你装饰来装饰去Q他的本质是不变的?p人带上了(jin)面具Q但他还是h。墙上打上了(jin)Ҏ(gu)Q但它还是墙呀。你也许觉得q是废话?但理解这点很重要(q是跟策略模式Strategy的区?Q本得这个是理解?Decorator 模式很重要的一炏V在开发中你经常要增强一个类的功能，或者是撤销一个类的某些功能，但是一个类l众多的功能q行装饰?jin)以后，也许原来的类已经面目全非了(jin)，你往往?x)感到茫(dng)其实Q你主要抓住他的MQ脑子里面时刻要知道你现在所作的工作是个主体进行打扮的工作?BR>研究qJive的都知道Q?里面?Filter 是用了(jin)Decorator 设计模式Q那么在q个设计里面Q它的主体是什么？ ForumMessage Q无疑是 ForumMessage 。装饰品当然是Filter ?jin)，所以我们在作这件事情的时候始l是以ForumMessage为核?j)的QFilter q行装饰的时候，你千万不要忘C现在是ؓ(f)ForumMessage而工作！有关于jive研究的文章，|上一大堆Q现在看看一个比较简单的 Decorator:
//比如有一个抽象构Ӟ(x)
public interface Component {
void operation();
}
//一个具体构Ӟ(x)
public class ConcreteComponent implements Component {
public void operation() {
//Write your code here
}
}
//一个抽象装饎ͼ(x)
public class Decorator implements Component {
private Component component; //引用
?? ? ?BR>//商业Ҏ(gu)Q委z构g
public void operation() {
component.operation();
}
}
//一个具体装饎ͼ(x)
public class ConcreteDecorator extends Decorator {
/**
* 商业Ҏ(gu)
*/
public void operation(){
//一些具体的装饰的代?/FONT>
......
super.operation(); // M
//一些具体的装饰的代?/FONT>
.......
}
}
......
我们主要看看Q在ConcreteDecorator 中的operation() Ҏ(gu)Q他的父cL委托到componentl徏来完成的Q其实它?yu)是MQ?一些装C码都?x)在q个Ҏ(gu)Q主体）(j)执行前进行“预处理”或是执行后q行“收䏀?BR>可不是，从上面很Ҏ(gu)qZ(jin)Q抽象装C的operation() Ҏ(gu)没有在具体的装饰cMq行“全盘”覆盖，因ؓ(f)他用?jin)super.operation(); q样的语句。可见装饰模式中不管怎么P 你都要找到类D个的Ҏ(gu)。说明他的主体还在?q是跟策略模式Strategy的区?
说了(jin)怎么多，不知道大家有没有感觉到ConcreteDecoratorcM的operation()Ҏ(gu)跟Spring AOP 中的 InvocationHandler 接口的invoke()Ҏ(gu)有点相类是呢Q?BR>我们来看看要实现 InvocationHandler 时候要重写的invoke()Ҏ(gu)Q?BR>
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
…………………?
result = method.invoke(originalObject, args);
…………………………?.
return result;
}
InvocationHandler.invoke Ҏ(gu)在被代理类的方法被调用之前触发。通过q个Ҏ(gu)中，我们可以在被代理cL法调用的前后q行一些处理，如上面代码中所C，InvocationHandler.invokeҎ(gu)的参C传递了(jin)当前被调用的Ҏ(gu)QMethodQ，以及(qing)被调用方法的参数。同Ӟ我们可以通过Method.invokeҎ(gu)调用被代理类的原始方法实现。这P我们可以在被代理类的方法调用前后大做文章。（说明Q引用了(jin)Spring 开发指南中的一D）(j)
在回到装饰模式，其方法operation() 在执行前和执行后Q也可以对它大做文章。如此看来， Spring AOP ?DecoratorQ从理解层面上来看，实有点相象Q注意：(x)只是理解层面Q?而他们的实现完全两马事！
其实主要是大家怎么看待q个问题Q按照本人的理解QSpring AOP 也可以说是一U广义的装饰Q但它又不是装饰模式。它同样也是Ҏ(gu)个方法加上了(jin)限制Q比如insert() 的时候，你要对它做执行前开启事务和执行后提交或回滚q样的“装饰”?又比如你也可以对某个人操作资源后做logq样的装饰工作。等{，Q?BR>他们的相同之处就q么炏V?BR>AOP 也不是什么新的东西，当然如果你的AOP是容?Jboss 4.0)实现的话Q?那么按照上面说的Q你的一些方法就?x)被容器所“装饰”?
如此看来Q更多的时候可以理解ؓ(f) Spring AOP 和一些AOP 容器是在pȝU的Q容器的“装饰”?而装饰模式则是业务的装饰?q点其实从客L(fng)也很Ҏ(gu)理解?BR>如果是AOP Q程序员可以攑ֿ(j)的写你的代码Q即使有点笨也不怕，有AOP护着呢）(j)?因ؓ(f)pȝ在pȝq行时候对q段代码q行“装饰”。也是_(d)q些装饰不会(x)出现在客L(fng)的代码中Q，Q而，Decorator模式呢？呵呵Q这个时候程序员要有点头脑了(jin)Q他们要自己l装一些装饰类Q按照某一U机制对Mq行装饰。也是_(d)q些修饰c要出现在客L(fng)的代码中。看代码q道了(jin) :--)
InputStreamReader input = new InputStreamReader(System.in);
BufferedReader br = new BufferedReader(input)Q?BR>....//M是System.in
?Q?够经典的例子Q?
http://www.jdon.com/jive/article.jsp?forum=91&thread=17341
]]>