工厂模式和策略模式之间的区别是什么?

工厂模式是一种创建模式。战略模式是一种操作模式。换句话说，工厂模式用于创建特定类型的对象。策略模式用于以特定方式执行一个操作(或一组操作)。在经典的例子中，工厂可能会创建不同类型的动物:狗、猫、虎，而策略模式将执行特定的动作，例如，移动;使用跑，走或Lope策略。

事实上，这两者可以一起使用。例如，您可能有一个创建业务对象的工厂。它可以根据持久性介质使用不同的策略。如果数据以XML形式存储在本地，则使用一种策略。如果数据位于不同的远程数据库中，则它将使用另一个数据库。

策略模式允许您多态地更改类的行为。

工厂模式允许封装对象创建。

加里说得很好。如果您使用的编码原则是抽象的，而不是“具体化”的，那么很多模式看起来就像是主题的变体。

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

• 工厂(方法)模式。

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

• 战略模式。

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

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

所以。如果你的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();
}
}

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

根据奥斯卡的说法和他的准则:

getCommand是工厂类，UnixCommand、WindowsCommand和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());
}


}

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

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

首先必须区分简单工厂和抽象工厂。第一个是一个简单的工厂，其中只有一个类作为对象创建的工厂，而在后者中，您连接到一个工厂接口(它定义了方法名称)，然后调用实现该接口的不同工厂，这些工厂应该具有基于某些标准的相同方法的不同实现。例如，我们有一个ButtonCreationFactory接口，它由两个工厂实现，第一个是WindowsButtonCreationFactory(创建具有Windows外观的按钮)，第二个是LinuxButtonCreationFactory(创建具有Linux外观的按钮)。因此，这两个工厂确实有相同的创建方法，但实现(算法)不同。您可以在运行时中根据您键入所需按钮的方法引用它。

例如，如果你想要带有Linux外观和感觉的按钮:

ButtonCreationFactory myFactory = new LinuxButtonCreationFactory();
Button button1 = myFactory.createButton(...);

或者你想要Windows按钮

ButtonCreationFactory myFactory = new WindowsButtonCreationFactory();
Button button1 = myFactory.createButton(...);

正是在这种情况下，它导致了一种策略模式，因为它区分了进行某些创建的算法。但是，它在语义上与它不同，因为它用于对象创建而不是操作算法。所以，基本上，抽象工厂使用不同的策略来创建对象，这使得它与策略模式非常相似。然而，AbstractFactory是创造性的，而Strategy模式是可操作的。在执行方面，它们的结果是相同的。

您不能仅仅通过查看代码或分类来理解其中的区别。要正确掌握GoF模式，请寻找它们的意图:

策略:“定义一系列算法，封装每个算法，并使它们可互换。策略让算法独立于使用它的客户而变化。”

工厂方法:定义一个用于创建对象的接口，但是让子类来决定实例化哪个类。工厂方法允许类延迟实例化到子类。

下面是关于这两种模式的意图和区别的详细解释

简单来说，策略模式更多的是运行时行为的创建，您不关心实现类。另一方面，工厂是运行时创建的具体类实例，它是由你使用任何行为(方法)公开的实现接口。

Factory(和Factory返回的FactoryMethod):

1. 创建型模式
2. 基于继承
3. 工厂返回一个工厂方法(接口)，该方法返回具体对象
4. 你可以用新的具体对象代替接口，客户端(调用者)不应该知道所有的具体实现
5. 客户端始终只访问接口，您可以在Factory方法中隐藏对象创建细节

看看这个维基百科的文章和javarevisited文章

策略模式:

1. 这是一种行为模式
2. 它是基于委派的
3. 它通过修改方法行为来改变对象的内容
4. 它用来在一系列算法之间切换
5. 它在运行时改变对象的行为

例子:

您可以为特定的项目(机票或购物车项目)配置折扣策略。在本例中，您将在7月至12月期间提供25%的折扣，而在1月至6月期间不提供折扣。

相关文章:

策略模式的真实例子

设计模式:工厂vs工厂方法vs抽象工厂

简而言之:

Factory用于创建具有相同行为的多个对象，而Strategy用于创建具有不同工作方式的一个对象。

Factory Pattern和Strategy Pattern之间的关键区别是在哪里执行操作。Factory Pattern对创建的对象执行操作(工厂类在创建后完成这项工作)，而Strategy Pattern对上下文类本身执行操作。

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

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

工厂模式是关于决定创建哪个对象，而策略模式是关于使用创建的对象。例如，使用哪种策略可以由工厂模式决定