裝飾模式允許模型的不同行爲

Question

我想知道，如果我希望我的模型（MVC的「M部分」）根據它們的起源引發異常，裝飾模式的使用是否好。我解釋一下自己。

我有一個叫做Game的類，它是模型的一部分。我有兩個視圖：一個GUI和一個命令行。當用戶輸入字符而不是數字時（例如），我希望我的模型爲命令行視圖引發異常。當然，我不希望這個異常由模型處理，因爲它「屬於」命令行而不是模型本身。爲了封裝這兩種不同的行爲，我打算用兩個類來裝飾Game類：CommandLineGame和GUIGame，它們只有一個屬性：Game和處理它們自己的Exception。這是個好主意嗎 ？有更好的嗎？這樣一個解決方案的問題是，每個模型類都會根據其起源而引發異常......

Answer 1

你在例子中描述的是「輸入驗證」。嚴格來說，這屬於MVC的控制器（「C部分」）。

對MVC關注點分離分解如下：

• 查看有：1）提出了一種UI爲用戶評估程序的狀態（另外，你的程序是什麼樣的視覺）和2）接收用戶的意圖表達（接收關於他們可能想要做的事的原始指令）
• 控制器是用戶對這些「動作」或「意圖」的實際解釋。它決定了用戶點擊某個特定按鈕以及在模型中調用什麼的意義。它決定了一個特定的輸入是否在UI的上下文（以及某些情況下來自模型）的情況下是有意義的。
• 模型應該是視圖/控制器不可知（意味着模型應該不知道視圖/控制器）。它只應該是關於你試圖「建模」的內部表示。這樣做的好處是：您可以擁有許多不同的UI，或者更改現有的UI而不影響模型。

總的來說，這個想法是降低耦合和增加內聚力。

我希望是有道理=）

取決於語言/框架，MVC組件之間的界限會模糊了一下。一些成語會將Controller的大部分放入View中，但是邏輯的封裝應該保持相對相似。

*在實踐中，防禦性編程，輸入驗證兩次相互猜疑做的：他們被分成客戶端中介和服務器端中介：

• 在這種情況下，模型部分應該處理「服務器端」調解：它應該檢查在繼續之前傳遞給它的函數的參數實際上是否有意義。
• 同樣，控制器/視圖部分應檢查輸入作爲「客戶端」調解的一部分，以便它可以立即警告用戶，而不必將其傳遞迴模型，然後再返回到視圖。

Answer 2

它會保持您的代碼非常乾淨，這是我從學術角度看的很多東西。 另一方面，您是否需要爲這樣的簡單問題引入這種設計複雜性？

所以，如果你需要代碼乾淨...去吧。