Builder设计模式和Factory设计模式之间的区别是什么？
哪一种更有利？为什么？
如果我想测试和比较/对比这些模式，我如何将我的发现表示为图表？
当前回答
工厂模式允许您一次创建一个对象，而生成器模式允许您中断对象的创建过程。这样，您可以在创建对象期间添加不同的功能。
其他回答
工厂模式允许您一次创建一个对象，而生成器模式允许您中断对象的创建过程。这样，您可以在创建对象期间添加不同的功能。
生成器和抽象工厂有着不同的目的。根据正确的用例，您必须选择合适的设计模式。
生成器的显著特点：
生成器模式使用简单对象和分步方法构建复杂对象生成器类逐步构建最终对象。此生成器独立于其他对象在这种情况下替换为Factory方法/抽象工厂：从客户端程序传递给Factory类的参数太多，容易出错某些参数可能是可选的，不像工厂中强制发送所有参数
工厂（简单工厂）的显著特点：
创建型模式基于继承Factory返回一个Factory方法（接口），然后返回具体对象您可以用新的具体对象替换接口，客户端（调用者）不应该知道所有具体实现客户端始终只访问接口，您可以在Factory方法中隐藏对象创建详细信息。
通常，设计从使用工厂方法（不那么复杂，更可定制，子类激增）开始，并向抽象工厂、原型或生成器（更灵活，更复杂）发展
查看相关帖子：
将生成器保持在单独的类中（流畅的接口）
设计模式：工厂vs工厂方法vs抽象工厂
有关详细信息，请参阅以下文章：
资源制造
日志记录设备
这两种模式都有相同的必要性：对某些客户端代码隐藏复杂对象的构造逻辑。但是，是什么使一个对象变得“复杂”（或有时变得复杂）？主要是由于依赖关系，或者更确切地说是由更多部分状态组成的对象的状态。您可以通过构造函数注入依赖项来设置初始对象状态，但一个对象可能需要很多依赖项，其中一些依赖项将处于默认初始状态（只是因为我们应该了解到，将默认依赖项设置为null不是最干净的方式），而另一些依赖项则设置为由某种条件驱动的状态。此外，有些对象财产是某种“不经意的依赖关系”，但它们也可以假定为可选状态。
有两种众所周知的方法来控制这种复杂性：
组合/聚合：构造一个对象，构造其依赖对象，然后连接在一起。在这里，构建器可以使确定引导组件构建的规则的过程透明而灵活。多态性：构造规则直接声明到子类型定义中，因此每个子类型都有一组规则，某些条件决定了这些规则中的哪一个适用于构造对象。工厂完全适合这种情况。
没有什么可以阻止这两种方法的混合。一个产品系列可以抽象对象创建，由生成器完成，生成器可以使用工厂来确定实例化哪个组件对象。
它们之间的主要区别在于，生成器模式主要描述一步一步创建复杂对象。在抽象工厂模式中，重点是对象系列产品。生成器在最后一步返回产品。在抽象工厂模式中，产品立即可用。
例子：假设我们正在创建迷宫
1.抽象工厂：
Maze* MazeGame::CreateMaze (MazeFactory& factory) {
Maze* maze = factory.MakeMaze(); /// product is available at start!!
/* Call some methods on maze */
return maze;
}
2.建造商：
Maze* MazeGame::CreateMaze (MazeBuilder& builder) {
builder.buildMaze(); /// We don't have access to maze
/* Call some methods on builder */
return builder.GetMaze();
}
两者都是创造模式，以创建对象。
1） 工厂模式-假设您有一个超级类和N个子类。对象的创建取决于传递的参数/值。
2） 生成器模式-创建复杂对象。
Ex: Make a Loan Object. Loan could be house loan, car loan ,
education loan ..etc. Each loan will have different interest rate, amount ,
duration ...etc. Finally a complex object created through step by step process.
