责任链与类列表相比有哪些优势?

2022-09-02 21:55:18

最近,我和另一位程序员讨论了重构一个充满“if”语句的巨大(1000行)方法的最佳方法。

代码是用Java编写的,但我想这个问题也可能发生在其他语言中,如C#。

为了解决这个问题,他建议使用责任链模式。他建议有一个基本的“处理程序”类。然后,“Handler1”,“Handler2”等将扩展“Handler”。
然后,处理程序将具有“getSuccessor”方法,该方法将返回 null(如果它是链中的最后一个)或链的下一个处理程序。
然后,“handleRequest(Request)”函数将处理 Request,或者将其传递给链的下一个,如果以前的解决方案都不起作用,它将只返回 null 或引发异常。
要向链中添加新的处理程序,编码人员将转到链的最后一个元素并告诉它存在一个新元素。要做点什么,他只需在链的第一个元素上调用handleRequest。

为了解决这个问题,我建议使用不同的方法。
我也有一个基本的“Handler”类,带有“Handler1”,“Handler2”,就像前面提到的方法一样。
但是,不会有“getSuccessor”方法。相反,我会有一个集合类,其中包含处理程序列表(Vector,ArrayList或在这种情况下最好的任何东西)。
handleRequest 函数仍将存在,但它不会将调用传播到下一个处理程序。它只会处理请求或返回 null。
要处理请求,可以使用

for(Handler handle : handlers){
    result = handle.handleRequest(request);
    if(result!=null) return result;
}
throw new CouldNotParseRequestException(); //just like in the other approach

或者,为了防止代码重复,可以将“parseRequest(request)”方法添加到集合类中。要添加新的处理程序,可以转到集合构造函数(或static{}块,或等效块),然后简单地添加代码“addHandler(new Handler3());”。

这种方法究竟缺少责任链的哪些优势?哪种方法是最好的(假设有最好的方法)?为什么?每种设计方法可能导致哪些潜在的错误和问题?

对于那些需要上下文的人来说,这是原始代码的样子:

if(x instanceof Type1)
{
//doSomething1
} else if(x instanceof Type2)
{
//doSomething2
}
//etc.

答案 1

哪种方法最好取决于您的处理程序想要做什么。

如果处理程序可以完全自行处理请求请求,则您的方法很好。处理程序没有对其他处理程序的引用,这使得处理程序接口变得简单。与责任链的标准实现不同,您可以在责任链的中间添加或删除处理程序。实际上,您可以根据请求的类型选择构建不同的链。

您的方法的一个问题是处理程序无法对请求进行预处理或后处理。如果需要此功能,则责任链更好。在CoR中,处理程序是负责委派给链上下一个处理程序的处理程序,因此处理程序可以进行预处理和/或后处理,包括修改或替换链上下一个处理程序的响应。通过这种方式,CoR与Experkor非常相似;只是意图不同而已。

由于在 CoR 中,处理程序保留对链上下一项的引用,因此您无法在链的中间添加或删除项。CoR的一个变体允许您在链的中间添加或删除项目,它是过滤器链(例如,请参阅javax.servlet.FilterChain)。

您展示的代码示例是一堆“if”语句,这些语句根据对象的类型执行不同的行为。如果这是您正在清理的代码的典型情况,则只需将请求类型映射到所需的处理程序即可。

删除“if”语句的另一种方法是继承。如果您有一些需要执行的行为,并且Web服务器有一个变体,SOAP服务器有其他变体,则可以有一个WebServerRequestHandler和SoapServerRequestHandler,每个都扩展了RequestHandler。继承的优点是有一个更清晰的地方来放置两种类型的请求通用的逻辑。缺点是,由于Java没有多重继承,因此您只能对一维问题进行建模。


答案 2

我喜欢你的想法与收集比那些继任者更好。它使操作这组处理程序变得简单明了:集合接口是众所周知的,每个人都知道如何迭代List或什么。

如果你使用朋友建议的这种后继方式,注意不要陷入非常深的递归(除非你的平台支持尾部调用,我不知道JVM是否能够做到这一点)。

我不建议向集合中添加任何方法。你会得到更复杂的设计,更难理解,更难修改。有两个不同的问题:存储一组处理程序以及将此处理程序解释为责任链。通过循环访问集合来处理请求的方法比集合内务管理方法具有更高的抽象级别,因此不应属于集合接口。