在运行时，根据用户行为和历史记录，我需要执行排序操作。在我的情况下，SortByDate/SortByDemand/SortByConsumption将只返回字符串，或者我们可以说order by clause（可能很复杂）。
在大多数论坛中，我发现应该使用策略模式进行排序。
我在这里附上了战略模式的图像。 Util类将调用三个类中的一个对象，即SortByDate / SortByDemand / SortByConsumption
因此，每次定义新的排序方法时，我都需要更改util类并定义新的策略。
但是，如果我使用工厂实现它，那么util类只需要调用工厂，它将负责调用哪个类。所以我想我应该使用工厂。
但是我已经读过，策略是满足这些需求的最佳模式。为什么策略模式在这里更好？
策略是一种模式，旨在允许您在不破坏算法客户端的情况下为您的软件添加新的（在您的情况下排序）算法。这是对设计复杂性的投资，如果您需要在不破坏客户的情况下添加新算法，这将获得回报。 Factory是一种补充策略的模式，因为算法实现的客户端不应该具体知道他们正在使用哪种实现（就软件类而言）。工厂实例化算法的具体实现，以便客户端可以在不知道细节的情况下使用它们。
这是静态结构：
这是动态的：
你所做的不是工厂模式，而是两者的混合，这一点并不清楚，而且在我看来是错误的。
在第二个示例中，类名是错误的并且令人困惑。 SortByDateFactory的行为不像工厂（它不会产生任何东西），但它确实表现得像一个策略。因此，它应该符合战略界面。
另一方面，在第一个例子中，UtilClass的行为与您想要的工厂相似。因此，我建议按原样保留第一个示例，但将UtilClass重命名为SortStrategyFactory。
这两个图都看起来像战略模式，但底部有一点点。如果你想要一个工厂，这意味着utilclass将是抽象的并且有一个工厂方法，它实例化一个分类器类。由utilclass的特定子类定义的特定类型的分拣机。
策略模式的要点是避免被绑定到类层次结构中，以便您可以将各种分类器与各种其他功能混合搭配。当您使用utilclass的子类时，工厂是合适的，并且特定的子类（其余部分的功能）总是需要特定的分类器，而不是一个不同的分类器。根据您的需求选择合适的产品。
你有效地使用工厂和战略。工厂决定创建哪种策略;策略执行排序逻辑。
您的底图令人困惑，因为您从工厂继承了您的策略。工厂应该制定正确的战略。
客户只是询问工厂的策略并使用它。