0

我有点困惑，在一本书中，iOS 上的游戏设计是使用 MVC 模式。所以我们有

  1. 视图，由界面生成器完成，并为控件的属性/值（作为插座）和事件处理程序（作为操作）绘制连接

  2. 模型，存储游戏的状态，例如剩余时间和当前玩家的得分（人类玩家）

  3. 控制器，在 View 加载后运行，将 Model 的数据填充到视图中，为游戏设置 Timer，处理用户在屏幕上的点击等（事件处理程序），并为 Timer 事件实现事件处理程序.

ComputerPlayer所以这是有道理的，但是还有第四个类叫做提供下一个单词供人类玩家猜测。 （更新：Model 类 100% 使用此 ComputerPlayer...Model 代码实例化了 ComputerPlayer 对象，然后对其进行调用）。

我不太明白为什么在这个 MVC 模型中，有一个额外的类ComputerPlayer？为什么不让这部分成为Model课堂的一部分，甚至成为Controller课堂的一部分？

（如果与 Ruby on Rails 的 MVC 模式相比，它有点像助手。但助手主要由视图代码调用。）

4

3 回答 3

1

MV* C * 模式中的C经常与不同的控制器对话。所以它不是一对一的关系。添加 ComputerPlayerController 在 MVC 模式中是完全有效的，并且值得鼓励。

于 2012-04-16T09:23:58.063 回答
1

MVC更像是一种架构组织，因此每个元素（M、V、C）通常是一组（或层）类。

也许您的书只为每个课程讲一个课程，从而使事情过于简单化了。我会将其ComputerPlayer视为模型层的一个元素。从维基百科页面可以看到，MVC 有很多解释/实现。

于 2012-04-17T15:50:44.540 回答
1

就像 Fuhrmanator 所说，ComputerPlayer 似乎被认为是模型层的一部分。但是，您也可以将其视为实用程序类。

在 MVC 中，Utility Class 不是任何层的一部分，可以被任何层访问。

于 2012-04-18T05:49:46.150 回答