工厂和战略模式

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

它绝对是战略与工厂的结合 - 但我不认为这很糟糕.这些图案旨在相互组合和使用.

很难说这个设计方案在上下文中是一个好的设计还是坏的设计.只有你在这里给出的信息,它可以是任何一种方式.

看起来你的头脑在正确的位置,但是让我给你一个警告:不要过于努力地将你的客户与你的策略区分开来.我过去已经这样做了,它导致了一个令人费解的混乱,如果我只是允许我的代码的两个部分之间的一点连接,这将简单得多.分离是好的,但努力保持完美分离可能导致错误的代码和各种问题.