关于View和ViewController的职责和沟通
我正在开发一款纸牌游戏 iPhone 应用程序，并且对通信方法和各个组件的责任有疑问。
在我的应用程序中，viewWillAppear 中的 ViewController 创建 View 类的实例并对其进行初始化。 ViewController 创建视图并强烈指向它。
[self setGameView:[[GameView alloc] initWithFrame:CGRectMake(0, 0, 480, 300)]];
在 GameView 内，我在视图上放置卡片并确保它们可以根据某些规则移动。
几个问题：
鉴于某些卡可以“击败”其他卡，视图或视图控制器是否应该负责此决定？例如，此时，任何卡都可以放置在任何卡的顶部，只要它们位于同一区域，但是，有时，卡应该弹回，而其他时候程序应该识别出该卡已经击败了另一张卡。
在这种情况下，视图是否应该通知其控制器“卡 A 被放置在卡 B 的顶部 - 弄清楚 A 是否真的击败了 B”。如果控制器认为 A 无法击败 B，则控制器应该指示其视图将 A 重新放入堆栈，就好像 A 确实击败了 B 一样，它应该保持在原来的位置，并且应该发生其他一些事情？
这里应该如何进行沟通？
我认为在它的 - viewWillAppear 方法中，ViewController 应该订阅 NSNotificationCenter 请求在下次将卡片放置在另一张卡片之上时发出通知。由于 View 属于 ViewController，它可以访问它的所有公共接口方法，并且可以从中找出什么卡在什么位置以及为什么。
NSNotification 是处理这个问题的好方法，还是有更好的方法？
正如你从我的问题中看到的，我在这里有点困惑。请帮我澄清这一点。
I am working on a card game iPhone app and have a question about both method of communication and responsibility of various components.
In my application, the ViewController in it's viewWillAppear, creates instance of the View class and initializes it. ViewController creates the view and points strongly to it.
[self setGameView:[[GameView alloc] initWithFrame:CGRectMake(0, 0, 480, 300)]];
Inside the GameView, i lay out cards on the view and make sure they can be moved according to some rules.
A few questions:
Given that some cards can "beat" other cards, should View or View Controller be in charge of this decision? For instance, at this point, any card can be placed on top of any card, as long as they are in the same region, however, sometimes, cards should snap back and other times program should recognize that card has beaten another card.
In this event, should View notify the its Controller that "card A is placed on top of card B - go figure out if A actually beats B". If Controller decides that A can't beat B, Controller should instruct it's view to snap A back to stack, where as if A indeed has beaten B, it should remain where it is and some other things should happen?
How should communication happen here?
I am thinking that in it's - viewWillAppear method, ViewController should subscribe to NSNotificationCenter asking to be made aware the next time card is placed on top of another card. Since View is owned by ViewController it has access to all of it's public interface methods and can figure out from there what card is in what place and why.
Is NSNotification a good way to handle this, or is there a better way to do it?
As you can see from my question, i am a bit confused here. Please help clarify this for me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，我想说 View 或 ViewController 都不负责卡片的行为。那应该是模型的领域。阅读模型视图控制器 核心能力。另请参阅与对象通信
视图应该将用户操作提供给模型，模型应该告诉视图如何反应。
至于传递信息的实际实现，NSNotifcations 是一个有效的选择。但是，还有其他选择，例如创建自定义 协议 协议是另一种做事的方式。它们需要定义一个委托对象来实现协议支持的消息。
如果您要使用 NSNotifications，我会将其结构如下：
这种结构将视图和模型分开，从而使代码和调试更加清晰。然后，ViewController 会执行视图控制器的操作，例如显示可能显示高分历史记录的其他视图控制器等。
使用协议执行上述操作将需要创建“用户更改”和“卡更改”协议，模型实现“用户更改” ”协议和实现“卡更改”协议的视图。然后，模型将视图作为其委托，视图将模型作为其委托。
To start with, I'd say that neither the View or the ViewController are in charge of how cards behave. That should be the realm of the Model. Take a read of Model View Controller core competencies. Also take a look at Communicating with Objects
The View should feed user actions to the Model, and the the Model should tell the View how to react.
As to actual implementation of passing information around, NSNotifcations are a valid choice. However there are other choices such as creating custom protocols Protocols are another way of doing things. They require defining a delegate object that fulfills the messages supported by the protocol.
If you were going to use NSNotifications, I would structure it like:
This structure separates the View and Model and hence makes things cleaner to code and to debug. The ViewController is then left to do View Controller things like displaying other View Controllers that might show hi score histories etc.
Doing the above with Protocols would require creating "User Change" and "Card Change" protocols, with the Model implementing the "User Change" protocol and the View implementing the "Card Change" protocol. The Model would then have the View as its delegate and the View would have the Model as its delegate.