工厂和战略模式有什么区别？
任何人都可以解释工厂和战略模式之间的区别吗？
对于我来说，除了额外的工厂类别（它们以工厂模式创build产品对象）之外，
工厂模式是一种创build模式。 战略模式是一种运作模式。 换句话说，工厂模式用于创build特定types的对象。 策略模式用于以特定方式执行操作（或操作集合）。 在典型的例子中，工厂可能会创build不同types的动物：狗，猫，老虎，而战略模式会执行特定的动作，例如移动; 使用Run，Walk或者Lope策略。
其实两者可以一起使用。 例如，您可能有一个创build您的业务对象的工厂。 它可以使用基于持久性媒介的不同策略。 如果您的数据本地存储在XML中，则会使用一种策略。 如果数据在不同的数据库中是远程的，则会使用另一个数据库。
策略模式允许你多态地改变一个类的行为。
工厂模式允许您封装对象创build。
加里说得很好。 如果你使用抽象的原则而不是“结实”，那么很多模式开始看起来像一个主题的变化。
为了增加tvanfosson的说法，很多模式看起来和实现一样。 也就是说，你可以创build一个接口，在你的代码中可能没有一个接口，然后创build一个接口的实现。 不同之处在于他们的目的以及如何使用它们。
- 工厂（方法）模式。
仅创build具体实例。 不同的参数可能会导致不同的对象。 这取决于逻辑等
- 战略模式。
封装algorithm（步骤）以执行操作。 所以你可以改变策略并使用另一种algorithm。
虽然两者看起来非常相似，但目的却相当不同，一个目的就是创造另一个就是要执行一个动作。
所以。 如果你的工厂方法是固定的，你可能会这样：
public Command getCommand( int operatingSystem ) { switch( operatingSystem ) { case UNIX : case LINUX : return new UnixCommand(); case WINDOWS : return new WindowsCommand(); case OSX : return new OSXCommand(); } } 但是，假设你的工厂需要更先进的或dynamic的创造。 您可以向工厂方法添加一个策略，并在不必重新编译的情况下更改它，策略可能会在运行时更改。
首先是简单工厂和抽象工厂的区别。 第一个是一个简单的工厂，只有一个类作为对象创build的工厂，而后者连接到一个工厂接口（它定义了方法名），然后调用实现这个接口的不同工厂基于某些标准应该有相同的方法不同的实现。 例如，我们有一个ButtonCreationFactory接口，它由两个工厂实现，第一个WindowsButtonCreationFactory（创build具有Windows外观的button）和第二个LinuxButtonCreationFactory（创build具有Linux外观的button）。 所以这两个工厂都有不同的实现（algorithm）具有相同的创build方法。 你可以在运行时根据你想要的buttontypes来引用它。
例如，如果你想要的button与Linux的外观和感觉：
ButtonCreationFactory myFactory = new LinuxButtonCreationFactory(); Button button1 = myFactory.createButton(...);
或者如果你想要Windowsbutton
ButtonCreationFactory myFactory = new WindowsButtonCreationFactory(); Button button1 = myFactory.createButton(...);
正是在这种情况下，它产生了一种策略模式，因为它区分了用于做一些创build的algorithm。 然而，它与语义不同，因为它用于OBJECT CREATION而不是运algorithm则。 所以，基本上在抽象工厂你用不同的策略来创build对象，这就和战略模式非常相似。 然而，AbstractFactory是创造性的，而Strategy模式是可操作的。 实施方面，他们的结果是一样的。
工厂（和工厂返回的FactoryMethod） ：
- 创造性的模式
- 基于inheritance
- 工厂返回一个工厂方法（接口），然后返回具体对象
- 你可以用新的具体对象代替接口，客户端（调用者）不应该知道所有具体的实现
- 客户端只能访问接口，您可以在Factory方法中隐藏对象创build细节
看看这个维基百科文章和javarevisited文章
战略模式：
- 这是一种行为模式
- 这是基于代表团
- 它通过修改方法行为来改变对象的内容
- 它用于在algorithm族之间切换
- 它在运行时改变对象的行为
例：
您可以为特定项目（AirFare ticket或ShoppingCart项目）configuration折扣策略。 在这个例子中，你将在七月至十二月期间提供一件商品的25％的折扣，而在六月的Jaunary期间，这个商品没有折扣。
相关文章：
战略格局的现实世界范例
devise模式：工厂vs工厂方法与抽象工厂
为了延续奥斯卡所说的和他的代码：
getCommand是Factory和UnixCommand，WindowsCommand和OSXCommand类是Strategies
简单来说，策略模式更多的是运行时创build行为，而不关心实现类。 另一方面，工厂是具体类实例的运行时创build，由您实现的接口公开的任何行为（方法）由您决定。
我可能会和奥斯卡一起离开，他的一个工厂实施的例子是相当紧密耦合，非常封闭，难怪你的select是战略模式。 工厂实现不应该依赖于任何固定数量的实例化的特定类，例如：
public Command getCommand( int operatingSystem ) { return commandTable.get(operatingSystem); } ... public class WindowsCommand implements Command { ... static { CommandTable.getInstance().registerCommand(WIN_COMMAND_ID, new WindowsCommand()); } }
我想最合适的select一个或另一个的标准主要是你用来命名你的类和方法的术语，考虑到我们都应该倾向于编程接口而不是类，并着眼于目标：我们的目标是确定哪些代码将在运行时执行。 也就是说，我们可以通过使用这两种模式来实现目标。
战略和工厂是不同的目的。 在战略中，你有方法定义，使用这种模式，你可以交换行为（algorithm）。 来到工厂周围有很多变化。 但是从GO4状态工厂的原始模式将对象创build到子类。 在这里工厂，你正在取代完整的实例不是你感兴趣的行为。由此，你将取代完整的系统而不是algorithm。
工厂模式是创build模式，使用指定的属性（行为）创build。 而在创build后的运行时间，你不能改变属性（行为）。 所以如果你需要不同的属性（行为），你必须删除对象，并创build新的对象与所需的属性（行为）。 这不是gud。 而在战略模式的情况下，你可以在运行时改变属性（行为）。
您只需查看代码或分类即可了解其差异。 为了正确掌握GoF模式，寻找他们的意图：
策略：“定义一系列algorithm，封装每一个algorithm，并使它们可以互换。策略可以使algorithm独立于使用algorithm的客户端。”
工厂方法：“定义一个接口来创build一个对象，但是让子类决定实例化哪一个类。Factory方法让一个类将实例化推迟到子类。
这里详细解释了这两种模式的意图和差异： 工厂方法和策略devise模式之间的区别
