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 回答