Design patterns Factory和Builder模式（混合两个或多个模式）

我知道这个问题被问了很多次，看起来这个问题可能是重复的，但我试图理解SO、Google、GoF上的帖子，却没有找到我的答案

我理解工厂方法和建筑商之间的区别： 工厂方法-创建从特定基类派生的对象，将具体实现与客户端分离

生成器方法-对客户端隐藏对象创建的复杂性

现在我看到了我在internet（）上找到的示例，它是关于一个抽象工厂的，但这和我的问题无关。这只是我看过的许多文章中的一篇

//Abstract Factory for Dependency Injection
//Factory interface
public interface Module1ServiceFactory {
 ComponentA getComponentA();
 ComponentB getComponentB();
}

//Concrete factory
public class Module1ServiceFactoryImpl {
 private Module1ServiceFactory instance;

 private Module1ServiceFactoryImpl() {}

 public static synchronized Module1ServiceFactory getInstance() {
  if (null == instance) {
   instance = new Module1ServiceFactoryImpl();
  }

return instance;
 }

*** SUBJECT METHOD ***
 public ComponentA getComponentA() {
  ComponentA componentA = new ComponentAImpl();
  ComponentB componentB = getComponentB();
  componentA.setComponentB(componentB);
  return componentA;
 }

 public ComponentB getComponentB() {
  return new ComponentBImpl();
 }
}

我在那个例子中看到，ComponentA是一个复杂类型，getComponentA（）方法用于构建它

那么，为什么这被称为工厂而不是建筑商？？？或者它意味着Module1ServiceFactoryImpl实现了工厂和构建器模式

在软件体系结构设计中创建实现多个设计模式的类/对象是否正确（常用）

---

对不起我的英语：）

工厂模式基本上隐藏了实例化具体对象（与构造函数不同），并强调了所创建对象的接口

相反，构建器模式通常有助于实现多步骤构建行为，其中某些步骤可能也是可选的。与构造函数（或工厂方法）不同，它强调将对象创建拆分为逻辑单元，而不是一次在语义上创建对象

我希望下面的示例可以更清楚地表达这种差异

public class ComponentABuilder {
  private ComponentB componentB;
  private ComponentC componentC;

  public ComponentABuilder BuildComponentB(ComponentB b) {
    this.componentB = b;
  }

  public ComponentABuilder BuildComponentC(ComponentC c) {
    // Added another ComponentC, since just building B would
    // be pointless
    this.componentC = c;
  }

  public ComponentA Build() {
    // Might also be implemented via setters or whatever, the
    // point is that build now returns an object that is fully
    // built according to the steps the consumer performed via
    // the builder's methods, whereas a Factory Method would
    // do all the stuff by theirself.
    return new ComponentA(this.componentB, this.componentC);
  }
}

// Consumer sticks together his very own ComponentA
// in (usually) multiple steps
ComponentA c = new ComponentABuilder()
  .BuildComponentB(new ComponentBImpl()) // step 1
  .BuildComponentB(new ComponentCImpl()) // step 2
  .Build();

// Factory builds their ComponentA according to their
// own internal application, and getInstance is exposed
// as an "atomic" step to the consumer
ComponentA c2 = new ComponentAFactory().getInstance();

构建器示例是一个非常特殊的案例，应用它是有意义的。但是，它也应该可以用于不同的应用程序

那么，为什么这被称为工厂而不是建筑商？？？或者它的意思是 Module1ServiceFactoryImpl是否实现工厂和构建器模式

它叫工厂，因为它是工厂，也是唯一的工厂

*** SUBJECT METHOD ***
 public ComponentA getComponentA() {
  ComponentA componentA = new ComponentAImpl();
  ComponentB componentB = getComponentB();
  componentA.setComponentB(componentB);
  return componentA;
 }

 public ComponentB getComponentB() {
  return new ComponentBImpl();
 }

我看这里没有建筑工人。当然，这不是最简单的方法，但若引入构建器模式，它肯定不会像它那个样复杂。这更像是JavaBean方式，在新创建的对象上使用setter。构建器模式要求在最后一步中创建对象，以使创建对象不可能处于就绪和未就绪之间的状态

创建包含以下内容的类/对象是否正确（常用） 在软件体系结构中实现多个设计模式 设计

是的，它是正确的，有时也会被使用。不是很常见，因为每个模式都会增加一些复杂性，而多个模式会增加多个复杂性：）但是，当然，您可以将builder与factory（builder需要一些分解的零件），facory与builder（factory封装了使用builder创建对象的用法）混合使用。模式在一起工作很好。MVC是一个很好的示例：

GOF（四的GON）不将MVC称为设计模式，而是将其视为“构建用户界面的类集合”。在他们看来，它实际上是其他三种经典设计模式的变体：观察者（Pub/Sub）、策略和复合模式。根据MVC在框架中的实现方式，它也可以使用Factory和Decorator模式

就我的两分钱：

Module1ServiceFactoryImpl似乎正在实现单例模式，所有字段和构造函数都是私有的，并且 getInstance（）用于获取self的新实例

如果Module1ServiceFactoryImpl实现了Module1ServiceFactory，那么它可能是一种工厂模式。然后，客户端代码可以使用 工厂的运作如下

---

Thx的答案，但它仍然不能解释为什么我的示例中的Module1ServiceFactoryImpl不是“构建器”。如我所见，public ComponentA getComponentA（）的功能与MyBuilder完全相同。Build（构建复杂对象）…IMHO

getComponentA

与生成器的功能不同。构建器向使用者公开多个步骤，而工厂可以执行但不公开这些步骤。我会再次思考如何更清楚地表达我的观点并编辑我的帖子。@AlexDn请再看一看新的示例，我对其进行了修改以更贴切地反映您的问题。我理解您所说的，但它再次在我的脑海中混乱了…您说“一个构建者向消费者公开了多个步骤…”-Module1ServiceFactory也这样做（ComponentA getComponentA（），ComponentB getComponentA（）），从另一端开始，生成器应“隐藏”复杂性，但有许多公开的方法，它看起来更复杂。例如，class Car:Factory可以创建汽车基础、发动机、门、车轮……但只有建筑商知道，在基础存在之前，发动机无法组装到汽车上……所以为什么建筑商应该公开不止一种方法？我同意它非常复杂。首先，例如，JoshuaBloch建议使用构建器而不是工厂（或构造函数）来减少参数数量，请参见。第二，您可以让不同的构建器实现决定使用哪些具体零件，而不是让消费者传递它们（就像我所做的那样）。在这种情况下，您可以让不同的实现来组装什么（什么汽车零件），而基础制造商决定如何组装它们（例如，发动机之前的汽车基础）。

class Client {
    public static void main(String[] args) {
        Module1ServiceFactory factory = Module1ServiceFactoryImpl.getInstance();
        ComponentA compA = factory.getComponentA();
        compA.printComponentA();

        ComponentB compB = factory.getComponentB();
        compB.printComponentB();
    }
}

class Module1ServiceFactoryImpl implements Module1ServiceFactory {
    private static Module1ServiceFactory instance;

    private Module1ServiceFactoryImpl() {
    }

    public static synchronized Module1ServiceFactory getInstance() {
        if (null == instance) {
            instance = new Module1ServiceFactoryImpl();
        }

        return instance;
    }

    public ComponentA getComponentA() {
        ComponentA componentA = new ComponentAImpl();
        ComponentB componentB = getComponentB();
        componentA.setComponentB(componentB);
        return componentA;
    }

    public ComponentB getComponentB() {
        return new ComponentBImpl();
    }
}

interface Module1ServiceFactory {
    ComponentA getComponentA();

    ComponentB getComponentB();
}

interface ComponentA {
    void setComponentB(ComponentB componentB);

    void printComponentA();
}

class ComponentAImpl implements ComponentA {
    ComponentB componentB;

    @Override
    public void setComponentB(ComponentB componentB) {
        this.componentB = componentB;
    }

    @Override
    public void printComponentA() {
        System.out.println("ComponentA");
    }
}

interface ComponentB {
    public void printComponentB();
}

class ComponentBImpl implements ComponentB {
    @Override
    public void printComponentB() {
        System.out.println("ComponentB");
    }
}