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執行將'運行'。