【问题标题】：decorator pattern to allow different behavior of a model装饰器模式允许模型的不同行为
【发布时间】：2012-10-23 14:07:44
【问题描述】：
我想知道如果我希望我的模型（MVC 的“M 部分”）根据它们的来源引发异常，使用装饰器模式是否很好。我自己解释一下。
我有一个名为 Game 的类，它是模型的一部分。我有两个视图：一个 GUI 和一个命令行。我希望我的模型在用户输入字符而不是数字时引发命令行视图异常（例如）。当然我不希望模型处理这个异常，因为它“属于”命令行而不是模型本身。
为了封装这两种不同的行为，我打算用两个类来装饰 Game 类：CommandLineGame 和 GUIGame，它们只有一个属性：Game 并处理它们自己的异常类型。这是个好主意吗 ？有更好的吗？这种解决方案的问题是，每个模型类都必须根据其来源引发异常...
【问题讨论】：
标签：
java
model-view-controller
decorator
【解决方案1】：
您在示例中描述的是“输入验证”。严格来说*，这属于 MVC 的 Controller（“C 部分”）。
MVC 的关注点分离分解如下：
-
View 用于 1) 为用户提供一个 UI 以评估程序的状态（以及您的程序在视觉上的样子）和 2) 接收用户的意图表达（接收原始指令他们可能想做什么）
-
控制器是用户对这些“动作”或“意图”的实际解释者。它决定了用户单击特定按钮的含义以及在模型中调用什么。它决定特定输入在给定 UI 上下文（在某些情况下来自模型）的情况下是否真正有意义。
-
Model 应该与 View/Controller 无关（意味着模型应该不知道 View/Controller）。它应该只是关于你试图“建模”的内部表示。这样做的好处是：您可以拥有许多不同的 UI，或者在不影响模型的情况下更改现有的 UI。
总的来说，这个想法是降低耦合并增加内聚。
我希望这是有道理的 =)
根据语言/框架的不同，MVC 组件之间的界限会变得有些模糊。有些习语会将Controller的大部分内容集中到View中，但逻辑的封装应该保持相对相似。
*在实践中，对于防御性编程，输入验证会进行两次以相互怀疑：它们分为客户端中介和服务器端中介：
- 在这种情况下，模型部分应处理“服务器端”中介：它应在继续之前检查传递给其函数的参数是否真正有意义。
- 同样，Controller/View 部分应该检查输入作为“客户端”中介的一部分，以便它可以立即警告用户，而不会将其传递回模型，然后最终返回视图。
【解决方案2】：
它将使您的代码非常干净，从学术角度来看，这是我非常喜欢的。
另一方面，对于这样一个简单的问题，您是否需要引入这种设计复杂性？
所以，如果您需要干净的代码...去吧。