3

我会尽量简短地描述问题......

线程池执行链式任务。每个任务都继承自一个抽象类。它们中的大多数处理外部服务，需要定制以与服务对话。每个任务将包含一个对象或对象列表，我们将其称为 TaskObjects，尽管它们可以是 String、Integer、MyClass 等。当任务完成时，它会将 TaskObject(s) 和其他数据放入响应集合中对象并将其传递。当任务链完成时，集合返回到主线程。

主线程将评估响应并根据这些响应确定要采取的操作。这些可能是即时操作（即，拉出 TaskObject，操作它们，并将结果放入新任务中以在下一个可用线程上执行），或者它可能需要累积 N 个该类型的响应以触发操作(即，拉出TaskObject(s)，可能对其进行操作，并将它们放置在本地集合中。如果N个TaskObject(s)在该集合中建立超过M时间，则对那些TaskObject(s)采取行动)。操作也可能基于响应发生的位置与响应集合中的其他任务相关，因此响应不能单独处理自己。

我面临的问题是处理一堆不同的任务对象。它们不继承自任何共享类（当然，Object 除外）。多态性无济于事。主线程评估的性质使事情变得复杂。我正在寻找选项，但它们似乎都不是非常“好”......

  • 委派任务/响应来处理事情、使用访客等。这将是困难的，因为每个任务都不知道除了自己的行为之外的任何事情以及下一个任务将是什么。他们必须绑定一些“集中式”服务来处理结果，这必须考虑线程安全，并且将所有响应捆绑到一个集合中会使事情变得复杂。可行，但我可能只是用一个烂摊子换另一个烂摊子。
  • 泛型。它可以帮助扁平化一些层次结构，但它不能解决主线程处理 TaskObjects 的问题，因为它不知道 T 是什么类型或如何处理它。你好类型检查条件。布莱赫。
  • 让自己彻底检查响应对象。
  • 在包含所有类型字段的响应中为 TaskObject(s) 创建一个包装器，并将其放置在抽象类中。现在我们可以对所有内容进行空检查以找出我们正在处理的内容。好不了多少。

我不确定是否有一种“好”的方式来处理这种事情。一般问题在 Java 中并不是很独特，但这种特殊的困境可能更是如此。也许没有干净的方法来处理这个问题，我只需要重构一点并实施最不坏的解决方案。

再说一次，我可能会让事情变得过于复杂，而更好的选择是坐在我的鼻子底下......

4

1 回答 1

0

根据您的描述，在我看来，您有两个地方可以看到各种任务：任务层次结构本身和主线程中的响应处理。这意味着添加新任务可能需要在这两个地方进行更改，这会降低您的代码的灵活性。

我想知道您是否可以将这种多样性封装在一个地方。一个想法是使用策略模式：在这种情况下，策略将定义处理逻辑，这取决于整个响应集合。一个特定的 Task 类将只包含对该策略的引用。这还需要像ITask使用一种方法一样创建一个接口，getProcessingStrategy(). 在您的情况下，策略界面需要能够适应您的复杂处理场景（例如execute(Collection<IResponse>)）。

最终，您将拥有任务类的层次结构和许多独立的处理策略。每个任务类都将指定要使用的策略。添加新的任务类需要决定使用哪种策略来处理任务响应。

于 2013-12-12T12:24:38.167 回答