1

我想知道如果我希望我的模型（MVC 的“M 部分”）根据它们的来源引发异常，使用装饰器模式是否很好。我自己解释。

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

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

4

2 回答 2

2

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

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

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

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

我希望这是有道理的=）

根据语言/框架的不同，MVC 组件之间的界限会变得有些模糊。有些习语会将大部分 Controller 集中到 View 中，但逻辑的封装应该保持相对相似。

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

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

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

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

于 2012-10-23T14:20:34.647 回答