为什么工厂不足以分拣？

Question

我在论坛中发现了这一点，似乎有很好的解释：

  

策略是一种模式，旨在允许您在不破坏算法客户端的情况下为您的软件添加新的（在您的情况下排序）算法。这是对设计复杂性的投资，如果您需要在不破坏客户的情况下添加新算法，这将获得回报。 Factory是一种补充策略的模式，因为算法实现的客户端不应该具体知道他们正在使用哪种实现（就软件类而言）。工厂实例化算法的具体实现，以便客户端可以在不知道细节的情况下使用它们。

     

     

但是我无法理解SortStrategtyInterface的需要。我们不应该只要求工厂返回排序字符串。

如果上面的某些内容是正确的，那么他们可以共享代码来调用它吗？还有一个例子，如果我删除SortstrategyInterface，那么它可以有什么缺点？

Answer 1

虽然界面并不完全“必要”，但最好还是确保客户端与不同排序算法之间的合约。该合同只是向客户确保方法'getSortString（）'存在于从工厂返回的任何策略中。从php5开始，代码看起来像这样：

$sorting_obj = SortStrategyFactory::getSorterBy("demand");
if ( ! $sorting_obj instanceof SortStrategyInterface ) {
  throw new \exception('contract failed, the sorting algorithm must implement the SortStrategyInterface');
}
$sorting_obj->getSortString();

# or maybe:
try {
  $sorting_obj = (SortStrategyInterface)SortStrategyFactory::getSorterBy("date");
} catch ( \exception $e ) {
  # ...
}
$sorting_obj->getSortString();

界面永远不是“真正”需要的，但它们的使用当然具有很多优点而没有真正的劣势。从长远来看，保持客户与实施之间的合同使得扩展变得更加简单。

Answer 2

策略模式（再次）并非“必要”，当它的使用符合您的需求时，它是一件好事。基本思想是你可以有一个共同概念的多个实现（排序）。从上面发布的相同示例中脱颖而出，策略模式将允许您添加更多“排序”实现，而无需更改现有客户端。

让我们假设您收到一个新的“SortByUser”的新要求，这个新任务只需要使用方法getSortString（）实现SortStrategyInterface，以及工厂中用于创建它的几行。从那里旧客户端将没有意外的副作用，新的/修改过的客户端将可以访问这种新的排序策略。根据我的经验，战略模式是最常出现的策略模式。每当您的原始要求要求对概念采用“替代”（关键字）方法时，您几乎可以立即想到策略模式。

Answer 3

策略允许您在运行时轻松添加算法。对我来说工厂应该足够了，但是根据理论，战略+工厂应该适合你。