我在一个论坛上找到了这个，它似乎解释得很好：
策略是一种模式，旨在允许您在不破坏算法客户端的情况下向您的软件添加新的（在您的情况下排序）算法。这是对设计复杂性的投资，如果您需要在不破坏客户的情况下添加新算法，它将获得回报。Factory 是一种补充 Strategy 的模式，因为算法实现的客户不应该具体知道他们正在使用哪个实现（就软件类而言）。工厂实例化算法的具体实现，因此客户端可以在不知道细节的情况下使用它们。
但是我无法理解 SortStrategtyInterface 的需要。我们不应该只要求工厂返回排序字符串吗？
另外，如果上面的事情是正确的，那么他们可以共享代码来调用它吗？还有一个例子，如果我删除 SortstrategyInterface，那么它会有什么缺点？
尽管该接口并非完全“必需”，但最好有一个接口来确保客户端与不同排序算法之间的合同。该合约只是向客户端保证方法“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();
从来没有“真正”需要接口，但它们的使用肯定有很多优点，没有真正的缺点。从长远来看，保持客户端和实现之间的合同使得扩展变得如此简单。
策略模式（再一次）不是“必需的”，当它的使用符合您的需求时，它只是一个很好的选择。基本思想是一个通用概念（排序）可以有多种实现。从上面发布的相同示例开始，策略模式将允许您添加更多的“排序”实现，而无需更改现有客户端。
假设您收到一个新的“SortByUser”的新要求，这个新任务只需要使用方法 getSortString() 实现一个 SortStrategyInterface，以及在工厂中创建它的几行代码。从那里，旧客户端将不会有意外的副作用，而新/修改后的客户端将可以访问这种新的排序策略。根据我的经验，策略模式是最常自然出现的模式。每当您的原始需求要求对概念采用“替代”（关键字）方法时，您几乎可以立即想到策略模式。
策略允许您在运行时轻松添加算法。对我来说，工厂应该足够了，但是根据理论，战略+工厂应该适合你。