java - 流畅的界面和 Builder 模式有什么区别？

Question

我对设计模式非常陌生，并且对 fluent interfaces 之间的区别感到困惑。和 builder 模式。

我了解流畅界面的概念。但是构建器模式有点令人困惑。我无法理解在 Builder 模式中使用 Director。

我可以同时使用 Builder 模式和 Fluent Interface 吗？如果是这样，那么我应该如何与导演和混凝土建筑商一起这样做？

我的问题不是关于构建器模式的优点。但是这个问题的目的是了解构建器模式和流畅界面之间的关系。

---

使用来自 GoF 的 Builder 的 UML 序列图进行编辑:

Answer 1

Fluent Interfaces是语义外观。您将它们放在现有代码之上，以减少语法噪音并更清楚地表达代码在通用语言中的作用。这是构建内部域特定语言时使用的模式。这是关于可读性的。

导演/ builder 协调某物的 build 。也就是说，如果您正在构建比萨饼烘焙机，Director 将确保从订单到比萨饼的步骤由正确的制造商使用正确的数据以正确的顺序执行。这是关于验证和授权的。

您当然可以在 Director/Builder 模式之上放置一个 Fluent Interface 以使其更流畅地阅读并强调领域概念(相对于构建和委派的技术过程)。那可能是 Expression Builder那么。

我想强调的是，Fluent 接口(interface)不仅仅是 Method Chaining .这是一个常见的误解。方法链是实现流畅接口(interface)的一种方法，但它并不相同，因为它缺乏语义质量，例如这不是一个流畅的界面:

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

以上内容并没有表达任何关于 SomeObject 的内容。它不是某些语义模型之上的外观。这只是一些链接的方法。 Fluent Interface 的一个示例是 SQL 查询构建器，例如

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

在该 API 的底层是创建 SQL 语句的代码。它可能包含多个对象，并且显示的调用可以很好地创建一个 Select 对象，在其上调用一个 setter，创建一个 Condition 对象并将其应用于 Select 对象，最后返回一个 Statement 对象。但是这一切对我们都是隐藏的。这也突出了 Fluent 接口(interface)的另一个方面:它们可能违反 SOLID和 Law of Demeter .但由于它是代码之上的外观，希望遵循这些设计原则，所以没那么重要，因为您将违规行为定位到 Fluent 接口(interface)。