让我们明确一点，在生产代码中，大多数时候我们使用抽象工厂模式，因为类A是用接口b编程的，而A需要创建b的实例，因此A必须有一个工厂对象来生成b的实例，因此A不依赖于b的任何具体实例，希望它有帮助。

两者的区别

“工厂方法”和“抽象工厂”的主要区别在于，工厂方法是方法，而抽象工厂是对象。我想很多人都把这两个词搞混了，开始交替使用。我记得当我学习它们的时候，我很难找到它们之间的确切区别。

因为工厂方法只是一个方法，它可以在子类中被重写，因此引用的后半部分:

．.． 工厂方法模式使用的 继承并依赖于一个子类 来处理所需的对象 实例化。

引用假设对象在这里调用自己的工厂方法。因此，唯一可以改变返回值的是子类。

抽象工厂是一个具有多个工厂方法的对象。看看你引言的前半部分:

．.． 使用抽象工厂模式，一个类 委托对象的职责 实例化到另一个对象 作文……

他们说的是，有一个对象A，想要创建一个Foo对象。而不是创建Foo对象本身(例如，使用工厂方法)，它将获得一个不同的对象(抽象工厂)来创建Foo对象。

代码示例

为了向你展示区别，这里有一个正在使用的工厂方法:

class A {
    public void doSomething() {
        Foo f = makeFoo();
        f.whatever();   
    }

    protected Foo makeFoo() {
        return new RegularFoo();
    }
}

class B extends A {
    protected Foo makeFoo() {
        //subclass is overriding the factory method 
        //to return something different
        return new SpecialFoo();
    }
}

这是一个正在使用的抽象工厂:

class A {
    private Factory factory;

    public A(Factory factory) {
        this.factory = factory;
    }

    public void doSomething() {
        //The concrete class of "f" depends on the concrete class
        //of the factory passed into the constructor. If you provide a
        //different factory, you get a different Foo object.
        Foo f = factory.makeFoo();
        f.whatever();
    }
}

interface Factory {
    Foo makeFoo();
    Bar makeBar();
    Aycufcn makeAmbiguousYetCommonlyUsedFakeClassName();
}

//need to make concrete factories that implement the "Factory" interface here

抽象工厂创建了一个基类，其抽象方法定义了应该创建的对象的方法。派生基类的每个工厂类都可以创建每种对象类型的自己的实现。

工厂方法只是一个用于在类中创建对象的简单方法。它通常添加在聚合根中(Order类有一个名为CreateOrderLine的方法)

抽象工厂

在下面的示例中，我们设计了一个接口，这样我们就可以将队列创建与消息传递系统分离，因此可以为不同的队列系统创建实现，而不必更改代码库。

interface IMessageQueueFactory
{
  IMessageQueue CreateOutboundQueue(string name);
  IMessageQueue CreateReplyQueue(string name);
}

public class AzureServiceBusQueueFactory : IMessageQueueFactory
{
      IMessageQueue CreateOutboundQueue(string name)
      {
           //init queue
           return new AzureMessageQueue(/*....*/);
      }

      IMessageQueue CreateReplyQueue(string name)
      {
           //init response queue
           return new AzureResponseMessageQueue(/*....*/);
      }

}

public class MsmqFactory : IMessageQueueFactory
{
      IMessageQueue CreateOutboundQueue(string name)
      {
           //init queue
           return new MsmqMessageQueue(/*....*/);
      }

      IMessageQueue CreateReplyQueue(string name)
      {
           //init response queue
           return new MsmqResponseMessageQueue(/*....*/);
      }
}

工厂方法

HTTP服务器的问题在于，我们总是需要为每个请求提供响应。

public interface IHttpRequest
{
    // .. all other methods ..

    IHttpResponse CreateResponse(int httpStatusCode);
}

如果没有工厂方法，HTTP服务器用户(即程序员)将被迫使用特定于实现的类，这就违背了IHttpRequest接口的目的。

因此，我们引入工厂方法，以便响应类的创建也被抽象出来。

总结

区别在于，包含工厂方法的类的预期目的不是创建对象，而抽象工厂应该只用于创建对象。

使用工厂方法时应该小心，因为在创建对象时很容易破坏LSP(里斯科夫替换原则)。

Understand the differences in the motivations: Suppose you’re building a tool where you’ve objects and a concrete implementation of the interrelations of the objects. Since you foresee variations in the objects, you’ve created an indirection by assigning the responsibility of creating variants of the objects to another object (we call it abstract factory). This abstraction finds strong benefit since you foresee future extensions needing variants of those objects. Another rather intriguing motivation in this line of thoughts is a case where every-or-none of the objects from the whole group will have a corresponding variant. Based on some conditions, either of the variants will be used and in each case all objects must be of same variant. This might be a bit counter intuitive to understand as we often tend think that - as long as the variants of an object follow a common uniform contract (interface in broader sense), the concrete implementation code should never break. The intriguing fact here is that, not always this is true especially when expected behavior cannot be modeled by a programming contract. A simple (borrowing the idea from GoF) is any GUI applications say a virtual monitor that emulates look-an-feel of MS or Mac or Fedora OS’s. Here, for example, when all widget objects such as window, button, etc. have MS variant except a scroll-bar that is derived from MAC variant, the purpose of the tool fails badly. These above cases form the fundamental need of Abstract Factory Pattern. On the other hand, imagine you’re writing a framework so that many people can built various tools (such as the one in above examples) using your framework. By the very idea of a framework, you don’t need to, albeit you could not use concrete objects in your logic. You rather put some high level contracts between various objects and how they interact. While you (as a framework developer) remain at a very abstract level, each builders of the tool is forced to follow your framework-constructs. However, they (the tool builders) have the freedom to decide what object to be built and how all the objects they create will interact. Unlike the previous case (of Abstract Factory Pattern), you (as framework creator) don’t need to work with concrete objects in this case; and rather can stay at the contract level of the objects. Furthermore, unlike the second part of the previous motivations, you or the tool-builders never have the situations of mixing objects from variants. Here, while framework code remains at contract level, every tool-builder is restricted (by the nature of the case itself) to using their own objects. Object creations in this case is delegated to each implementer and framework providers just provide uniform methods for creating and returning objects. Such methods are inevitable for framework developer to proceed with their code and has a special name called Factory method (Factory Method Pattern for the underlying pattern). Few Notes: If you’re familiar with ‘template method’, then you’d see that factory methods are often invoked from template methods in case of programs pertaining to any form of framework. By contrast, template methods of application-programs are often simple implementation of specific algorithm and void of factory-methods. Furthermore, for the completeness of the thoughts, using the framework (mentioned above), when a tool-builder is building a tool, inside each factory method, instead of creating a concrete object, he/she may further delegate the responsibility to an abstract-factory object, provided the tool-builder foresees variations of the concrete objects for future extensions. Sample Code: //Part of framework-code BoardGame { Board createBoard() //factory method. Default implementation can be provided as well Piece createPiece() //factory method startGame(){ //template method Board borad = createBoard() Piece piece = createPiece() initState(board, piece) } } //Part of Tool-builder code Ludo inherits BoardGame { Board createBoard(){ //overriding of factory method //Option A: return new LudoBoard() //Lodu knows object creation //Option B: return LudoFactory.createBoard() //Lodu asks AbstractFacory } …. } //Part of Tool-builder code Chess inherits BoardGame { Board createBoard(){ //overriding of factory method //return a Chess board } …. }

我的第一个问题是关于抽象工厂。它的角色是否允许您在其中创建一系列具体对象(这取决于您使用的具体工厂)，而不仅仅是单个具体对象?

是的。抽象工厂的目的是:

提供一个接口，用于创建一系列相关或依赖的对象，而无需指定它们的具体类。

根据调用的方法，抽象工厂只返回一个非常大的对象还是多个对象?

理想情况下，它应该为客户端调用的每个方法返回一个对象。

我的理解是，工厂方法模式有一个Creator接口，它将使ConcreteCreator负责知道要实例化哪个ConcreteProduct。这就是使用继承来处理对象实例化的意思吗?

是的。工厂方法使用继承。

抽象工厂模式委托对象实例化的责任通过组合到另一个对象?这是什么意思?

AbstractFactory定义了一个FactoryMethod，而ConcreteFactory负责构建一个ConcreteProduct。只需按照本文中的代码示例进行操作。

你可以在SE的相关文章中找到更多细节:

工厂模式和抽象工厂模式之间的基本区别是什么?

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

让我们明确一点，在生产代码中，大多数时候我们使用抽象工厂模式，因为类A是用接口b编程的，而A需要创建b的实例，因此A必须有一个工厂对象来生成b的实例，因此A不依赖于b的任何具体实例，希望它有帮助。