Java 允许模型的不同行为的装饰器模式

我想知道，如果我想让我的模型（“MVC的M部分”）根据其来源引发异常，使用装饰器模式是否合适。我解释自己

我有一个叫做Game的类，它是模型的一部分。我有两个视图：GUI和命令行。我希望我的模型在用户输入字符而不是数字（例如）时引发命令行视图的异常。当然，我不希望这个异常被模型处理，因为它“属于”命令行，而不是模型本身

---

为了封装这两种不同的行为，我计划用两个类来装饰游戏类：CommandLineGame和GUIGame，它们只有一个属性：Game和handle它们自己的异常类型。这是个好主意吗？有更好的吗？这种解决方案的问题是，每个模型类根据其来源引发异常都必须进行修饰…

它将使您的代码非常干净，从学术角度来看，这是我非常喜欢的。 另一方面，对于这样一个简单的问题，您是否需要引入这种设计复杂性

---

所以，如果你需要代码是干净的。。。开始吧。

您在示例中描述的是“输入验证”。严格来说*，这属于MVC的控制器（“C部分”）

MVC关注点的分离分解如下：

• 查看是否有1）为用户提供一个UI，以评估程序的状态（以及您的程序在视觉上的外观）和2）接收用户的意图表达（接收关于他们可能想要做什么的原始指示）
• 控制器是用户对这些“动作”或“意图”的实际解释者。它决定了用户单击特定按钮的含义以及在模型中调用的内容。它决定一个特定的输入在UI（在某些情况下还包括模型）给定的上下文中是否有意义
• 模型应该是视图/控制器不可知的（这意味着模型应该不知道视图/控制器）。它应该只是关于你试图“建模”的内部表示。这样做的好处是：您可以拥有许多不同的UI，或者在不影响模型的情况下更改现有UI

总的来说，这个想法是为了降低耦合并增加内聚

我希望这是有道理的

根据语言/框架的不同，MVC组件之间的界限会变得模糊一些。有些习惯用法会将大部分控制器合并到视图中，但逻辑的封装应该保持相对相似

*实际上，对于防御性编程，输入验证是为了相互怀疑而进行两次的：它们被分解为客户端中介和服务器端中介：

• 在这种情况下，模型部分应该处理“服务器端”中介：它应该在继续之前检查传递给其函数的参数是否有意义
• 类似地，控制器/视图部分应该作为“客户端”中介的一部分检查输入，以便它可以立即警告用户，而无需将其传递回模型，然后最终返回到视图