java - 装饰器模式允许模型有不同的行为

Question

我想知道使用装饰器模式是否很好，以防我希望我的模型(MVC 的“M 部分”)根据异常的来源引发异常。我解释一下。

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

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

Answer 1

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

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

• View 的作用是 1) 向用户呈现一个 UI，以评估程序的状态(以及程序的视觉效果)，2) 接收用户的意图表达(接收有关他们可能想做的事情的原始指示)
• Controller 是用户这些“ Action ”或“意图”的实际解释者。它决定用户单击特定按钮的含义以及在模型中调用的内容。它决定特定输入在给定 UI 上下文(以及在某些情况下来自模型)的情况下是否真正有意义。
• 模型应该与 View / Controller 无关(这意味着模型不应该了解 View / Controller )。它应该只是关于您试图“建模”的内容的内部表示。这样做的优点是:您可以拥有许多不同的 UI，或者更改现有的 UI，而不会影响模型。

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

我希望这是有道理的 =)

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

*实际上，对于防御性编程，输入验证会进行两次以防止相互怀疑:它们分为客户端中介和服务器端中介:

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