建造者模式和 LSP
Builder Pattern and LSP
我正在研究构建器模式，有几个问题我认为需要澄清
- 构建器模式是通过抽象class还是通过接口实现的。很少有帖子使用接口 https://sourcemaking.com/design_patterns/builder
https://refactoring.guru/design-patterns/builder
...can list more
and others uses abstract class https://www.dofactory.com/net/builder-design-pattern
注：我认为的方式是应该使用Abstract来实现class。这个理由是基于这样的假设，即我 may/may 不会在派生 class 中实现它们（因为有可能一些具体的 class 不会实现它们）...
不过，这个假设可能是完全错误的。
- 如果上述假设是错误的，那么它不会违反LSP。由于 LSP 中的一个条件说您不能在派生的 class.
中有“未实现的方法”
或者我完全误解了...
评论太长了...
GoF 书中的模式早于 Java。正是 Java 后来引入了接口和抽象之间的（愚蠢的）区别 class。当 GoF 提到接口时，它们只是表示抽象，您可以使用任何支持抽象的语言特性来实现它。
也就是说，GoF Builder Pattern 过于复杂了。 The pattern is useful even without polymorphism. 我认为这是最常实施的方式。如果您使用的是 Java，那将是来自 Effective Java.
的 Josh Bloch 的构建器模式
我并不是要驳回 LSP 问题，但如果这里的真正目标是学习有效地使用 Builder，那么我的建议是忽略 GoF 的（过时的）版本并查看现代的在没有出现该问题的情况下实施。如果您真的想问关于 LSP 的问题，那么我建议提出一个专门针对该主题的新问题，与构建器模式分开。
为了更直接地解决 OP 中的问题，
- 建造者模式可以通过抽象classes或者通过接口来实现。哪个都没关系。现代实现更经常使用两者。
- LSP 一致性将取决于您如何实现（和记录）模式。使用接口或抽象 classes 有可能违反（或不违反）LSP。消除两者就消除了这个问题。
我正在研究构建器模式，有几个问题我认为需要澄清
- 构建器模式是通过抽象class还是通过接口实现的。很少有帖子使用接口 https://sourcemaking.com/design_patterns/builder
https://refactoring.guru/design-patterns/builder
...can list more
and others uses abstract class https://www.dofactory.com/net/builder-design-pattern
注：我认为的方式是应该使用Abstract来实现class。这个理由是基于这样的假设，即我 may/may 不会在派生 class 中实现它们（因为有可能一些具体的 class 不会实现它们）...
不过，这个假设可能是完全错误的。
- 如果上述假设是错误的，那么它不会违反LSP。由于 LSP 中的一个条件说您不能在派生的 class. 中有“未实现的方法”
或者我完全误解了...
评论太长了...
GoF 书中的模式早于 Java。正是 Java 后来引入了接口和抽象之间的（愚蠢的）区别 class。当 GoF 提到接口时，它们只是表示抽象，您可以使用任何支持抽象的语言特性来实现它。
也就是说，GoF Builder Pattern 过于复杂了。 The pattern is useful even without polymorphism. 我认为这是最常实施的方式。如果您使用的是 Java，那将是来自 Effective Java.
的 Josh Bloch 的构建器模式我并不是要驳回 LSP 问题，但如果这里的真正目标是学习有效地使用 Builder，那么我的建议是忽略 GoF 的（过时的）版本并查看现代的在没有出现该问题的情况下实施。如果您真的想问关于 LSP 的问题，那么我建议提出一个专门针对该主题的新问题，与构建器模式分开。
为了更直接地解决 OP 中的问题，
- 建造者模式可以通过抽象classes或者通过接口来实现。哪个都没关系。现代实现更经常使用两者。
- LSP 一致性将取决于您如何实现（和记录）模式。使用接口或抽象 classes 有可能违反（或不违反）LSP。消除两者就消除了这个问题。