|
锁定老帖子 主题：请问责任链真的是一种设计模式吗
精华帖 (2) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-07-28
通常弱化发送者和接收者之间的耦合关系和增加修饰这两个要求是同时存在的。或者说是互相依存的。
如果不能把发送者和接收者解耦的话，就不可能很容易的添加修饰。 而且从具体的实现来看，把Decorator的实现结构看作职责连没有任何问题。 我还特意去翻了一下GOF的原著，里面2个模式的典型情况在结构上确实是相同的。 只不过职责连的变种比较多罢了。 模式中几乎都是你中有我，我中有你。将他们完全割裂开来没有什么意义。 |
| 返回顶楼 | |
|
发表时间：2007-07-29
1、实现的代码一样不能说明什么问题，如果说实现的类似，代理模式与装饰模式更加类似。
例如：aBorderDecorator.component->aScrollDecorator.componnent->aTextView 这是装饰模式的对象结构. aClient.subject->aProxy.subject->aRealSubject 这是代理模式的对象结构. aClient.aHandler->aConcreteHandler.successor->aConcreteHandler.successor 这是责任链模式的对象结构 描述模式的除了实现的代码样例之外，还有动机、限制、使用场合的东西。这些代表了思考和抽象外部世界的模式。责任链的动机是动态构造一条对象链，并将请求沿着对象链传递，重点在怎么构造这样一条对象链条。装饰的动机是动态的为一个对象添加一些额外的职责。从动机上说，代理和装饰更加接近，按照宝典的说法，装饰为对象添加新的业务功能，而代理则控制对对象的访问（例如，屏蔽远程对象的访问差异、延迟加载对象等）。 2、如果不能把发送者和接收者解耦的话，就不可能很容易的添加修饰。这个我不赞同，解耦与增加装饰不一定相关，不管对象的接口如何都是可以添加装饰的，其意图是不需要生成子类的情形下即可给对象添加职责，从而避免了静态实现所有功能组合，导致子类急剧增加。 |
| 返回顶楼 | |
|
发表时间：2007-07-30
qinysong 写道 所以上面的重构代码，只需把firstElement 放到上面即可，如下所示，已通过测试，和你的效果一样 firstElement += 1;
for (; firstElement < handlerConfigs.length ; firstElement++) {
if (handlerConfigs[firstElement].getPattern().matcher(doRegex).matches()) {
handlerConfigs[firstElement].getHandler().executeHandler(this);
return;
}
}
这个改法不错，之前有个哥们说到了，我之前没有认真得去想他的话，他说： solospider 写道 嗯，思想不错。
不过就是有点不明白executeHandler() 为什么要用递归，一个循环遍历不就行了？ 递规是我自然而然的去想到的，想到之后我就进了套子，认为这里只有递规了，也没有多想了，呵呵，谢谢，还是这个遍历比较好，其实俺也比较讨厌递规，出了问题不好找。 qinysong 写道 单向依赖法则是我从无环依赖原则(ADP)推演的，ADP表达包和包之间不能存在相互依赖，包是一种实体，而类也是一种实体，只不过小于包实体，所以类之间虽然在特殊的情况下不能避免循环依赖，但只要可能最好还是避免，这样得到的设计会更简单、更清晰和容易理解 首先，您能从ADP中推演单向依赖法则证明您对它的理解非常深入，这让我钦佩，但是我却不能同意包是一种实体的说法（抑或我对这个实体的定义的理解有偏差），我倒是觉得类之间的循环依赖并没有什么不妥。之所以这样说是因为到处都有这种情况，比说tomcat，webwork，等 netpcc 写道 我还特意去翻了一下GOF的原著，里面2个模式的典型情况在结构上确实是相同的。 只不过职责连的变种比较多罢了。 就是因为责任链的变种多，就让我觉得他不应该是一种模式，呵呵（有点偏执了），查了一下headfirstdesignpattern，这本书里貌似也没有责任链这个模式的描述。 |
| 返回顶楼 | |
|
发表时间：2007-08-09
模式本来就是一种思想，我觉得，不仅为解决某类问题的一种方案，更是一种思想的体现。面向oo的编程方式是在接触了模式之后，当然了只是我个人感受
|
| 返回顶楼 | |
|
发表时间：2008-04-25
挺好呀，真的受益了，我现在也正在研究设计模式呀，想与楼主交个朋友，不知可不可以，我的Msn为cljspn@hotmail.com如果可以就加我。不想就算了哈哈
|
| 返回顶楼 | |
|
发表时间：2008-05-20
任何递归都是可以改写成循环
|
| 返回顶楼 | |
|
发表时间：2008-05-20
我认为这更像一种框架，我认为
模式，是一种思想，是不能以具体的编码代替各种具体情况的，不能简单的移植代码使用的 框架，是一种产品，是可以以具体的编码代替各种具体情况的，是可以将代码移植并使用的 比如，楼主的第三种方式，代码是可以直接拿到别的地方使用的，只需具体实现Handler就可以了。 |
| 返回顶楼 | |
|
发表时间：2008-06-30
用第一种方式实现的职责链可以在runtime选择下一个handler是谁,但是用第二种就不能,用第三种就需要把这个放在配置里.灵活性,还是第一种最好.
|
| 返回顶楼 | |
