战略和工厂是不同的目的。在策略中，您已经定义了方法，使用此模式可以交换行为(算法)。来到工厂有很多变化。但是GO4状态工厂的原始模式将对象的创建留给了子类。这里用工厂替换的是完整的实例，而不是你感兴趣的行为。这样你将取代整个系统，而不是算法。

战略和工厂是不同的目的。在策略中，您已经定义了方法，使用此模式可以交换行为(算法)。来到工厂有很多变化。但是GO4状态工厂的原始模式将对象的创建留给了子类。这里用工厂替换的是完整的实例，而不是你感兴趣的行为。这样你将取代整个系统，而不是算法。

工厂(方法)模式。

只创建具体实例。不同的参数可能导致不同的对象。这取决于逻辑等等。

战略模式。

封装算法(步骤)以执行操作。所以你可以改变策略，使用另一种算法。

虽然两者看起来非常相似，但目的却截然不同，一个目的是创造，另一个目的是执行动作。

所以。如果你的Factory方法是固定的，你可以像这样:

 public Command getCommand( int operatingSystem ) { 
      switch( operatingSystem ) { 
           case UNIX    :
           case LINUX   : return new UnixCommand();
           case WINDOWS : return new WindowsCommand();
           case OSX     : return new OSXCommand();
       }
  }

但是假设您的工厂需要更高级或更动态的创建。你可以在工厂方法中添加策略并在不需要重新编译的情况下更改它，策略可以在运行时更改。

我可能会偏离Oscar的主题，因为他的工厂实现的例子是紧密耦合且非常封闭的，难怪您选择了策略模式。工厂实现不应该依赖于任何固定数量的被实例化的特定类，例如:

public Command getCommand( int operatingSystem ) {        
   return commandTable.get(operatingSystem); 
}

...

public class WindowsCommand implements Command {
    ...
    static {
        CommandTable.getInstance().registerCommand(WIN_COMMAND_ID, new WindowsCommand());
    }

}

我想选择一个或另一个最合适的标准主要是用于命名类和方法的术语，考虑到我们都应该倾向于针对接口而不是类编程，并关注目标:我们的目标是确定哪些代码将在运行时执行。也就是说，我们可以通过使用这两种模式中的任何一种来实现目标。

只是补充一下tvanfosson所说的，就实现而言，很多模式看起来都是一样的。也就是说，很多时候你创建了一个接口，而在你的代码中可能没有，然后创建了该接口的一堆实现。区别在于它们的目的和使用方式。

工厂模式和策略模式之间的关键区别是在哪里进行操作。工厂模式对创建的对象执行操作(工厂类在创建后完成工作)，而策略模式对上下文类本身执行操作。

若要将工厂模式更改为策略模式，则不从工厂类返回创建的对象，将对象保存在上下文类中，并在上下文类中创建包装器方法来执行操作，而不是直接从创建的对象执行操作。

虽然有人可能会问我们是否可以对创建的对象进行操作，但为什么我们仍然需要在上下文类中创建包装器呢?好的，关键是操作。策略模式可以根据策略改变操作，而且不需要改变对象，可以依靠上下文对象来做不同的操作，而不需要改变对象本身。