GoF建设者和Liskov替代原则

Question

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

  

在Builder中默认为空方法。在C ++中，构建方法是   故意不宣布纯虚拟成员函数。他们是   相反，定义为空方法，让客户端只覆盖   他们感兴趣的行动。

不是空方法违反LSP吗？它看起来类似于继承Ostrich的{​​{1}}，Bird。

Answer 1

LSP声明你不能在不做同样事情的情况下覆盖父方法，加上与方法目的不矛盾的额外行为。

通常首先调用父方法，然后执行额外处理。

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

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

Answer 2

您的示例（从具有Ostrich方法的Bird类创建fly()绝对是违反LSP的示例。

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

  

他们将其定义为空方法，让客户端覆盖   仅对他们感兴趣的操作。

因此，在这种情况下，如果要在Ostrich类中创建Bird类，该类具有空 fly()方法且Ostrich不会覆盖它，然后它不会造成任何伤害，因为虽然它在那里它没有力量。

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

Answer 3

鸵鸟不能飞，但可以跑。因此，我建议在fly界面中将Bird方法重命名为action。 Eagle实施将会“飞行”。并且Ostrich实施将“正在运行”。