fluent界面和Builder模式有什么区别？

Question

我对设计模式非常陌生，并且对fluent接口和Builder模式之间的区别感到困难。

我理解fluent接口的概念。但建筑商的模式有点令人困惑。我不明白如何在Builder模式中使用Director。

我可以一起使用Builder模式和Fluent界面吗？如果是的话，我应该如何与一名署长和一名混凝土建造者一起这样做呢？

我的问题是而不是关于构建器模式的优势。但这个问题的目的是了解生成器模式与fluent界面之间的关系。

从GoF用UMLSequence图编辑Builder：

​

​

Answer 1

Fluent界面背后的理念是，通过将一个对象与点连接起来，可以将多个属性应用到一个对象上，而不必每次都对对象进行重新划分。构建器模式背后的思想是，与不可共享的不可变对象相比，不可共享的可变对象通常更容易处理，但对于共享不可变对象的推理要比对共享不可变对象的推理容易得多。因此，代码可以使用容易操作的可变对象来生成所需实例的“模型”，然后使用该模型使保存相同数据的易于共享的不可变对象。

这两种想法可以很好地结合在一起，但有些正交。

请注意，fluent界面至少有三种工作方式：

• 通过让实例的每个成员返回一个新实例，并应用适当的更改。
• 通过让每个成员对调用它的实例进行变异并返回该实例。
• 通过让每个成员返回一个轻量级修补程序对象的实例，该对象包含一个指向正在修改的东西或前一个修补程序的链接。

最后一种样式要求采取一些操作来应用所有修补程序，但如果要修改的对象很大，并且需要进行许多更改，则可以将所需的复制量降到最低。

Answer 2

Fluent接口是语义外观。您可以将它们放在现有代码之上，以减少语法噪音，并更清楚地表达代码在一种无处不在的语言中所做的事情。它是构建内部领域特定语言时使用的一种模式。是关于可读性的。

导演/建筑工人策划某物的建造。也就是说，如果您正在构建一台Pizza烘焙机，那么主管将确保从order到比萨的步骤按照正确的顺序执行，并由正确的构建者提供正确的数据。这是关于验证和授权的。

当然，您可以将一个流利的界面放在Director/Builder模式之上，使其更流畅地阅读，并强调领域概念(相对于构建和委派的技术过程)。那可能是一个表达式生成器。

我想强调的是，流利的界面不仅仅是方法链。这是一个常见的误解。方法链接是实现Fluent接口的一种方法，但并不相同，因为它缺乏语义特性，例如，这不是一个Fluent接口：

SomeObject.setFoo(1).setBar(2).setBaz(3);

上面的内容并没有表达任何关于SomeObject的内容。它不是某种语义模型之上的外观。只是有些方法被锁住了。Fluent接口的一个例子是SQL查询生成器。

SQLBuilder.select('foo').from('bar').where('foo = ?', 42).prepare();

在该API的幕后隐藏着创建SQL语句的代码。它可能包含多个对象，所显示的调用很可能会创建一个Select对象，调用其上的setter，创建一个条件对象并将其应用于Select对象，最后返回一个语句对象。但所有的一切都是对我们隐藏的。这也突出了Fluent接口的另一个方面:它们可能违反实心和德米特定律。但是，由于它是代码之上的一个外观，希望遵循这些设计原则，所以这并不重要，因为您将违反的地方定位到了Fluent界面。