符合 Liskov 的狀態設計模式

Question

我正在設計一個訂單系統，狀態設計模式似乎很合適，因為訂單可以更改其狀態，從而可以更改訂單允許的功能。 下面是我的基本類圖：

我不喜歡這種方法，因為客戶無法看到某個方法是否受支持並且違反了 Liskov 原則。 我在下面創建了一個替代方案：

我更喜歡這個，但客戶端仍然必須檢查是否支持一種方法。 但是他們仍然可以調用不受支持的方法並獲得異常。 這是否仍然違反 Liskov 原則？

是否有更好的設計符合 Liskov 並防止用戶調用特定狀態的無效方法？

Answer 1

你展示的不是狀態模式。 狀態模式在其內部狀態改變時改變對象行為。 例如，當您切換燈時，燈開關可以打開或關閉燈，具體取決於其狀態（同一方法的不同行為）。

使用此 Order 接口（4 種差異方法），我看不到引入狀態模式的任何好處。 它只會無緣無故地使事情復雜化。 但我不知道所有細節，所以接下來要做什么取決於你。

檢查此鏈接以查看狀態模式實施的示例https://sourcemaking.com/design_patterns/state