请教一个责任链的问题

在阎宏的<java与模式>一书中说道"发出这个请求的客户端并不知道链上的那一个对象最终处理这个请求,这使得系统可以在不影响客户端的情况下动态地重新组织链和分配责任."

但我地疑惑就在书中的两个例子中.
例1:
抽象处理类:Handler
具体处理类:ConcretHandler
client:
public class Client
{
static private Handler handler1,handler2;
public static void main(String args[])
{
handler1 = new ConcretHandler();
handler2 = new ConcretHandler();
handler1.setSuccessor(handler2);
handler1.handleRequest();
}
}
例2:<红楼梦>中击鼓传花
client:

public class DrumBeater
{
private static Player;
static public void main(String[] args)
{
player = new JiaMu(new JiaZheng(new JiaBaoYu(new JiaHuan(null))));
player.handle(4);
}
}

在上述两个例子中,chain的组成顺序逻辑都是client决定的,如果要重新组织chain,client端
的代码势必要有改动.这与书中本章开始提到的"不影响客户端的情况下动态的重新组织链"矛盾.

请大家指点.

你分析得很深刻,而且你的怀疑是对的。

关于他的定义:
"发出这个请求的客户端并不知道链上的那一个对象最终处理这个请求,这使得系统可以在不影响客户端的情况下动态地重新组织链和分配责任."

这段定义不是很精确,对于CoR,是在这样的前提下才能够使用:
处理请求者如果无法确定请求内容,或者需要将请求处理机制和请求内容解耦,才会使用CoR。
CoR基本和客户端没有什么关系,是事件处理机制的一种实现模式。


如果能够确定请求内容,那么直接使用Command模式是最快的,例如,如果你给你的请求加一个ID,并且规定,ID为1,调用command1.java;ID为2,调用command2.java,那么这就是Command模式了。

你提的这段代码,可以说是错误的,甚至是误导初学者。
在客户端中当然是不能进行CoR的排定设定。

责任链的最好范例就是servlet规范中的filter啦,那个是典型的责任链模式,你说得对,这两个不是责任链模式

关于《Java与模式》,我也想说几句。
上次参加UML培训,做练习时我做了一张用来表现神雕侠侣中各人之间关系的类图。老师说这样是不对的,像“杨过”“小龙女”这样的,不能作为一个个类存在于类图中,因为类是一类抽象的集合。其实道理很简单的,但应用在uml中就没有想到。后来我想,可能是受了“Java与模式”的影响,因为该书中大量这样的用法。如上面提到的红楼梦中各人物,都是这样表现出来的。
就好像我们平时确定类之间的关系,可以有公司、部门这样的抽象含义作为类,但肯定不会有“华为”“微软”这样的类。我觉得老师说的还是对的。所以,是否可以认为该书中这样的用法有失偏颇呢?
大家怎样看的。

提出异议:

怎么说在客户端不能设定COR 的顺序???

>怎么说在客户端不能设定COR 的顺序???

COR目的就是解除和客户端的耦合关系,看看GOF的定义:
使多个对象都有机会处理请求,从而避免请求的发送者和接受者的耦合关系....

如果你在客户端定义了COR的顺序,那么不是违反了CoR的使用原则?
这个例子正好违反了CoR的定义。

下面是作者阎宏博士的回复:

"这个例子需要改善。

排定顺序需要另一个对象负责,责任链模式本身不负责,客户也不负责。为了简便,我的书中的那个例子简化了。"

可是也不能简化到都违反定义了啊,本来举例是为了说明定义,结果反而是推翻定义,只用简化的理由我觉得是不能成立的。

不是我不依不饶,实在这个太那个了。

文过饰非,不肯老实承认错误...

其实认个错改正了也没什么啊

我看他的书大家也不必仔细去看了,本来也不咋样

《java与模式》前几章介绍设计原则的内容还可以,后面对设计模式的解释实在是糟糕,尤其老是引用中国古代故事,解释的一塌糊涂,让人看后对设计模式的认识反而更模糊了,应该列为“初学者不宜阅读”之类的书籍!

如果照你说的,是违反了COR的原则


可是如果单从设计模式和模式在实际中的应用来说,在客户端设定COR 的顺序是不是未常不可??

《java与模式》是一本好书,前几章介绍设计原则的内容当然还可以,后面对设计模式的解释也很好,我是在那本书上搞明白visitor模式,对于那些故事倒不是关键的问题,每个人写书有自己的方法和风格,不用强求,我的个人观点,

学习设计模式,就是要象摸象样的学,深入一些,一下子弄明白了,不然就别学,我对所谓的想降低难度来学习设计模式的各种小故事等等,就象《程序员》12期的设计模式电视机没有什么兴趣


以上是我的个人观点!

>如果照你说的,是违反了COR的原则
>可是如果单从设计模式和模式在实际中的应用来说,在客户端设定COR 的>顺序是不是未常不可??

设计模式本身就是应用实践的总结,对于设计模式只有一个方向,就是实际应用,因此不能对设计模式的研究分理论和实际两个标准,它只有唯一标准,就是如何应用?如何正确应用?

只有正确应用才便于他人理解,否则还不如不应用来得更通俗易懂。

目前最忌讳的就是错误应用,就象假冒名牌一样,坏了设计模式的声誉,导致不少人反设计模式,如果我们的学习书籍都是这样,那么设计模式在程序员中会是怎样的形象啊。

坚持真相,揭穿伪科学,减少对初学者的误导,无论对方是自己的老师或学友,这是我们每个严谨的程序员应该具备的态度。(这种方式在现实生活中可能难以实行,在网络上应该容易一点吧)

同意banq的观点,设计模式是对实践的总结,不是谁的发明创造,也必定要对实践起指导作用。如果连示例都是错的,那不学也罢

既然板桥不依不饶,我也跟着较较劲

本人纯粹是讨论问题,无其它意思,如果说的不对,请指正

我最初是看GOF的书,翻了一边,什么也没有看明白
然后看banq的例子,才慢慢死记硬背地了解一些了,后来仔细看一下,banq的例子比较简单,容易给初学的人以误导
现在再看看,才明白这里那里都有问题隐藏在那里,容易出问题

我的个人观点,也谢谢banq大哥的帮助