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

Question

我想知道在我希望我的模型（MVC的“M部分”）根据其来源引发异常的情况下是否使用装饰器模式是好的。我自己解释一下。

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

为了封装这两种不同的行为，我打算用两个类来装饰Game类：CommandLineGame和GUIGame只有一个属性：Game并处理它们自己的Exception。这是个好主意吗 ？还有更好的吗？这种解决方案的问题在于每个根据其来源引发异常的模型类都必须进行修饰......

Answer 1

您在示例中描述的是“输入验证”。严格来说*，它属于MVC的Controller（“C Part”）。

对MVC的关注点分离如下：

• 查看是1）为用户提供用于评估程序状态的UI（此外，您的程序在视觉上看起来如何）和2）接收用户的意图表达（收到关于他们可能想做什么的原始说明）
• 控制器是用户对这些“操作”或“意图”的实际解释。它决定了用户点击特定按钮以及在模型中调用的内容意味着什么。它根据UI（在某些情况下来自模型）给出上下文来决定特定输入是否真正有意义。
• 模型应该是视图/控制器不可知的（意味着模型应该不了解视图/控制器）。它应该只是关于你试图“模仿”的内部表征。这样做的好处是：您可以拥有许多不同的UI，或者在不影响模型的情况下更改现有的UI。

总的来说，这个想法是降低耦合并增加凝聚力。

我希望这有道理=）

根据语言/框架的不同，MVC组件之间的界限会变得模糊不清。一些习惯用法会将大部分Controller都归入View中，但逻辑的封装应保持相对类似。

*在实践中，对于防御性编程，输入验证会因相互猜疑而进行两次：它们分为客户端中介和服务器端中介：< / p>

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

Answer 2

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

所以，如果你需要干净的代码......去吧。