工厂模式和策略模式

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

我知道以下选项：

1）使用策略模式，伪代码如下：

interface Strategy {
  processResultSet(ResultSet rs);
}

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

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

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

class Context {
  private Strategy strategy;

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

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

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

它是策略和工厂的混合，还是实际上只是工厂模式？

这绝对是策略和工厂的结合 - 但我认为这还不错。这些模式旨在相互组合和使用。

如果不结合上下文来看这个设计方案，很难判断这是一个好设计还是一个坏设计。仅凭您在此处提供的信息，就可以采取任何一种方式。

看来你的头脑是对的，但让我警告你一句：不要太努力地将你的客户与你的策略分开。我过去曾经这样做过，它导致了一个令人费解的混乱，如果我只允许我的代码的两个部分之间有一点联系的话，情况会简单得多。分离是好事，但努力保持完美的分离可能会导致糟糕的代码和各种问题。