GoF生成器和Liskov替换原理

Question

在GoF中，有一部分关于生成器实现问题。其中一人说：

在Builder中默认为空方法。在C++中，构建方法是 故意不声明纯虚拟成员函数。他们 定义为空方法，而不是，让客户只覆盖了 操作他们感兴趣的问题。

不空方法违反LSP？它看起来类似于从Bird继承Ostrich那可以fly。

Answer 1

LSP指出，如果不做至少同样的事情，您不能重写父方法，以及不违背方法目的的额外行为。

这通常是通过先调用父方法，然后执行额外处理来实现的。

因为在这里，父方法什么都不做，覆盖它不违反原则，（当提供的方法名称被称为“add”时，你不会执行像“substract”这样的操作）。

必须保证父母在未来的实施中继续不做任何事情。所以可以肯定的，只是调用父空方法以防万一......

Answer 2

你的榜样（从Bird类具有fly()方法创建Ostrich）肯定是违反LSP的一个例子。

但在这种情况下采取这样的例子是不公平的。如果你清楚地看到像你说的

他们定义为空的方法代替，让客户覆盖 只有他们感兴趣的操作。

在这种情况下

所以，如果一个人要创建一个Ostrich类出Bird类有一个空fly()方法和Ostrich不会覆盖它，那么就不会做任何伤害，因为虽然它在那里它没有力量。

但是有些人可能会说，虽然从技术上来说确实不错，但从概念上讲，这样做并不好。所以实际上它不是模式的问题，但是我们面临着不同语言的实现限制。

Answer 3

鸵鸟不能飞，但可以运行。因此，我建议在Bird界面中将fly方法重命名为action。 Eagle执行将'飞行'并且Ostrich执行将'运行'。