Question

我需要创建一个负责结果集处理的类，但可能会使用不同的算法来处理结果集。

我知道以下选项：

1）使用策略patern，下面是伪代码：

interface Strategy {
  processResultSet(ResultSet rs);
}

class StrategyA implements Strategy {
  processResultSet(ResultSet rs);
}

class StrategyB implements Strategy {
  processResultSet(ResultSet rs);
}

Context类将包含对Strategy的引用，Client应该通过Strategy创建Context对象的实现，即

class Context {
  private Strategy strategy;

  public Context(Strategy strategy) {
    this.strategy = strategy;
  }

  public doSomething(rs) {
    strategy.processResultSet(rs);
}

问题在于我不想将策略对象传递给Context，但我想创建类似StrategyFactory的东西，它将负责创建具体的策略实现。它将客户与战略分开 - 这是一个好的设计吗？

它是战略和工厂的组合还是实际上只是工厂模式？

Answer 1

这绝对是战略与工厂的结合 - 但我不认为这很糟糕。这些模式旨在相互结合使用。

在上下文中看到这个设计方案，这是一个好的设计还是一个糟糕的设计很难说清楚。只有您在此处提供的信息，它可以采用任何一种方式。

好像你的脑袋在正确的位置，但是让我给你一个警告：不要过于努力地将你的客户与你的策略区分开来。我过去已经这样做了，它导致了一个复杂的混乱，如果我只是允许我的代码的两个部分之间的一点联系，这将简单得多。分离是好的，但努力保持完美分离可能导致错误的代码和各种问题。

Answer 2

我们已经使用了很多不同的解析方案，它确实有效。我在博客中写了一个代码示例：http://www.herrodius.com/blog/136

我们使用的技巧是给策略接口一个额外的“canProcess”方法，如果策略能够处理数据，它只返回一个布尔值。然后工厂简单地遍历其所有策略，并询问每个策略是否可以处理数据。如果可以，我们会返回该策略或执行策略。

Answer 3

在您描述的场景中，实际上并不需要一个Context，而是替换为您想要的Factory。在这种情况下，策略模式只是开销和不必要的复杂层。您只需要一个接口或抽象类，实现，以及用于检索实现的Factory或Proxy。

Answer 4

Anny评论与我的想法有关：

1）有一个服务 - 单身人士。 2）它包含对DAO类的引用 - 它也是一个单例。 3）在DAO中有一个检索ResultSet的方法：ResultSet rs = ps.executeQuery（）;我想在DAO中创建一个适当的策略来处理这个结果集。我无法在DAO构造函数中传递此策略，因为它特定于incomming请求。在构造函数中传递它会使所有incomming请求都相同。所以我决定在DAO（DAO对象实例）中创建一个Factory，在一个方法中，我将从工厂创建一个适当的策略（基于请求 - 本地对象）并使用它来处理结果集。

您认为此解决方案是否合适？

Answer 5

我认为战略模式应该采用工厂模式。在某种程度上，你使用它是绝对正确的。其次，如果将上下文类保留为抽象类会更好，这样您就可以根据需要扩展不同的上下文。其余的东西似乎很好，但根据你提到的例子，我认为没有必要，但你已经正确地使用了它。

工厂＆amp;战略模式

5 个答案: