为什么不进行工厂模式排序？

Question

在运行时，根据用户行为和历史记录，我需要执行排序操作。在我的情况下，SortByDate/SortByDemand/SortByConsumption将只返回字符串，或者我们可以说order by clause（可能很复杂）。

在大多数论坛中，我发现应该使用策略模式进行排序。

我在此处附加了战略模式的图像。 Util类将调用三个类中的一个对象，即SortByDate / SortByDemand / SortByConsumption

所以每次定义一个新的排序方法时，我都需要更改util类并定义一个新的策略。

但是，如果我使用工厂实现它，那么util类只需要调用工厂，它将负责调用哪个类。所以我想我应该使用工厂。

但是我已经读过，策略是满足这些需求的最佳模式。为什么策略模式在这里更好？

Answer 1

你所做的不是工厂模式，而是两者的混合，这一点并不清楚，在我看来是错误的。

在第二个例子中，类名是错误的并且令人困惑。 SortByDateFactory不像工厂（它不会产生任何东西），但它的行为就像一个策略。因此，它应该符合战略界面。

另一方面，在第一个示例中，UtilClass的行为与您要制作的工厂相似。因此，我建议保留第一个示例，但将UtilClass重命名为SortStrategyFactory。

Answer 2

这两个图表看起来都像是策略模式，但是底部的图表稍微提了一下。如果你想要一个工厂，这意味着utilclass将是抽象的并且有一个工厂方法，它实例化一个分类器类。由utilclass的特定子类定义的特定类型的分拣机。

策略模式的要点是避免被绑定到类层次结构中，以便您可以将各种排序器与各种其他功能混合搭配。当您使用utilclass的子类时，工厂是合适的，并且特定的子类（其余部分的功能）总是需要特定的分类器，而不是一个不同的分类器。根据您的需求选择合适的。

Answer 3

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

这是静态结构：

这是动态：

Answer 4

您正在有效地使用 factory 和策略。 factory 决定创建哪个策略; 策略执行排序逻辑。

您的底图令人困惑，因为您从工厂继承了您的策略。工厂应该创建正确的策略。

客户只是询问工厂的策略并使用它。