如何让每个班级互相交流？ [英] How to let each class interact with each other?

问题描述

我需要帮助理解iPad / iPhone环境中的MVC模型。不知何故，即使多次阅读，我也无法理解。

I need help in understanding MVC model in iPad/iPhone environment. Somehow I can't understand it even after reading several times.

假设我想构建一个存储图像位置的小应用程序，以及每个图像的注释。我可能会创建一个存储这些信息的SZImage类。除了setter和getter之外，我还需要实现其他方法吗？模型的作用是什么，它可以实现哪些方法以及它不能做什么？

Let's say I want to build a small application that store image location, and the comment for each image. I will possibly create a "SZImage" class that store these information. Aside from setter and getter, do I need to implement other methods? What is the role of model, what methods can it implement and what it can't do?

之后，我需要设置界面来显示图像。所以我需要创建另一个名为SZImageView的类。这门课的作用是什么？它是在iPhone窗口上绘制还是将其留给控制器来完成工作。如果我留给控制器绘制，那我为什么要创建这个类？

After that, I will need to setup the interface for displaying image. So I need to create another class with name "SZImageView". What is the role of this class? Does it draw on the iPhone window or I leave it to the controller to do the job. If I leave to the controller to draw, then why should I create this class?

如果我需要让控制器成为模型和视图之间的桥梁，那么应创建名为SZImageViewController的类。这堂课应该做什么？

And if I need to have controller to be the bridge between the model and view, then a class with name "SZImageViewController" should be created. What should this class do?

最后，这是一个令我困惑很久的人。如何在其他类中使用该方法向AppDelegate添加窗口？如何在类中实例之间进行交互。因为我看到AppDelegate通常非常简短。

Last, this is the one that have been confusing me for a long time. How can I use the method in other class to add window to the AppDelegate? How does the interaction between instance within class be done. Because I see that the AppDelegate is usually very short and simple.

推荐答案

模型 - 视图 - 控制器类别类别和示例

在模型 - 视图 - 控制器（MVC）中，每个类都应设计为适合这三个类别之一。这样做可以避免类耦合并创建更灵活的代码。

Model-View-Controller Class Categories and Examples

In Model-View-Controller (MVC), every class should be designed to fit into one of these three categories. In doing so, you can avoid class coupling and create much more flexible code.

模型类。
此类别的类别应该代表应用程序的数据模型。如果应用程序是游戏，那么代表玩家的类，敌人，关卡布局，保存的数据（如记分板）等等。 但是这些类应该仅限于保存代表这些对象的数据及其背后的逻辑。例如，如果它是一个赛车游戏，那么Car类应该是模型的一部分，它应该代表汽车的所有属性（例如它的速度，加速度，转弯等）。这个类还应该包括汽车所需的所有逻辑，例如确定汽车应该如何移动的逻辑（例如加速和断开，转弯），以及在碰撞等情况下应该发生什么。这个'Car'类应 note 定义汽车如何呈现给用户。这个类也不应该涉及任何应用程序逻辑。它应该完全坚持描述它是什么样的汽车。

Model Classes. Classes of this category should represent the application's data model. If the application is a game then classes that represent the player, enemies, level layouts, saved data (such as scoreboards) and so on. But these classes should be restricted only to holding the data that represents these objects and the logic behind them. For example, if it's a racing game, the class 'Car' should be part of the model, and it should represent all the properties of a car (for example it's speeed, acceleration, turning etc.). This class should also include all the necessary logic for the car, for example logic that determines how the car should move (such as acceleration and breaking, turning), and what should happen in the event of a collison and so on. This 'Car' class should note define how the car is presented to the user. Nor should this class involve any application logic. It should stick completely to describing what it is to be a car.

查看类。
此类别的类别应代表应用程序将模型呈现给用户的方式。与前面的示例一起，属于此类别的类的示例将是MainMenu，ScoreBoardView和RenderingEngine。 'MainMenu'类确切地知道如何向用户显示选项列表以及如何看起来非常漂亮。它还知道，当选择其中一个选项时，它应该略微改变其视觉外观，例如出现推入的按钮。但是，这个类不知道按下按钮时要做什么逻辑。这是控制器类的工作。因此，视图类只是让相关控制器知道用户已经与用户界面进行了交互（通过调用某种控制器方法或发送通知）。更多关于控制器部分的内容。

View Classes. Classes of this category should represent the way in which the application presents the model to the user. Keeping with the previous example, examples of classes that fall into this category would be a 'MainMenu', 'ScoreBoardView', and 'RenderingEngine'. The 'MainMenu' class knows exactly how to display a list of options to the user and how to look really beautiful. It also knows that when one of the options is selected, it should change its visual appearence slightly, such as a button appearing "pushed in". However, this class doesn't know what logic to do when a button is pressed. This is the job of the controller classes. So the view classes simply let the relevant controller know that the user interface has been interacted with by the user (by either calling some controller method or sending a notification out). More on this in the controllers section.

ScoreboardView也知道当它传递字符串（模型类）的字符串和数字（​​玩家姓名和分数）时它是以特定的方式呈现它们，也许是在表格中。它不知道如何更新字典，也不知道如何计算平均分数。如果它想要更多信息，那么它需要向控制器询问它。然后是控制器的工作，找出获取信息的方法。

"ScoreboardView" also knows that when it's passed a dictionary (model class) of strings and numbers (player names and scores) that it is to present them in a particular way, perhaps in a table. It doesn't know how to update the dictionary, nor how to calculate the average score. If it want's more information then it needs to ask the controller for it. It's then the controller's job to figure out a way of getting the information.

最后，对于本节，RenderingEngine是一个视图类，因为它需要一个模型并生成视觉效果。就是这样。 RenderingEngine被编程为知道如何显示汽车，并且如果汽车被设置在特定位置，那么它应该被绘制在这个位置，或者如果汽车已经碰撞，那么它需要通过屈曲来绘制。但同样，它不知道如何更新汽车的位置，也不知道速度等等。

Finally for this section, a "RenderingEngine" is a view class because it takes a model and produces visuals for it. And that's it. The RenderingEngine is programmed to know how to display a car, and that if the car is set to be in a particular location then it should be drawn in this location, or if the car has collided then it needs to be drawn with buckling. But again, it doesn't know how to update the position of the car, nor the speed and so on.

控制器类。
最后，正如我之前已经略微提到的那样，控制器是将所有内容组合在一起的类，并为您的应用程序提供流程和控制。人们已经将控制器类称为应用程序的大脑，因为它们根据用户的输入（通过视图类引导）和数据模型（可通过模型类访问）做出决策。
控制器类控制应用程序的流程。他们将用户从主菜单带到汽车选择屏幕到赛道，再到比赛到记分牌屏幕等等！它们通过类对模型进行更改，并提供对视图类的更改的反馈，以便这些类可以向用户显示应用程序的当前状态。控制器有效地将模型和视图链接在一起，同时提供应用程序逻辑和程序工作流程。此程序工作流还可以包括处理从视图中获取的输入与模型不匹配的问题。该视图对模型知之甚少，无法提供必要的检查 - 这是控制器的工作之一。因此，将视图类与模型类直接链接通常被认为是不好的做法。在这三种类中，控制器通常是最不可互换的类，但实际上它是您想要交换最多的视图和模型类。

Controller Classes. Finally, and as I've already previously slightly alluded to, controllers are the classes that bring everything together, and provide the flow and control for your application. People have refered to the controller classes as the "brains" of the application because they make decisions based on the user's input (which is channeled through the view classes) and the data model (which is accessible through the model classes). The controller classes control the application's flow. They take the user from the "main menu" to the "car selection screen" to the "race track" to the "race" to the "scoreboard screen" and so on! They make changes to the model through the classes and they provide the feedback of changes to the view classes so as those classes can present the current state of the application to the user. Controllers effectively link the model and the view together, while at the same providing application logic and program workflow. This program workflow can also include handling issues where the input that is taken from the view does not fit correctly with the model. The view has very little knowledge of the model and can't provide the necessary checks - this is one of the jobs of the controller. For this reason, it's generally considered bad practice to directly link the view classes with the model classes. Of the three types of classes, the controllers are generally the classes that are the least interchangeable, but in practice it is the view and model classes that you would want to interchange the most.

结论。模型 - 视图 - 控制器设计模式允许开发人员逻辑地组织他们的工作和他们的应用程序的组件。当使用模型 - 视图 - 控制器范例时，它保持灵活性，因为可以替换三个组件中的任何一个，只要替换模块保持与其他两个组件期望能够相互作用的相同协议。 （当我说协议时，这可以设计可以使用继承实现，或者在某些情况下，最好使用实际的协议声明并确保类确认适当的协议。）一个完美的例子就是很多为Mac编写的应用程序可以很容易地转移到iOS，因为两个平台之间唯一的主要区别在于用户界面级别，这完全可以理解，因为Mac的界面传统上是用户通过其进行交互的大屏幕另一方面，用于iOS的界面包括一个小得多的屏幕，用户触摸该屏幕进行交互。

Conclusions. The model-view-controller design pattern allows developers to logically organize their work and the components of their applications. When the model-view-controller paradigm is used it maintains flexibility because any of the three components can be replaced, so long as the replacement module keeps to the same protocol that the other two components expect to be able to intereact with. (When I say "protocol", this can design can either be implemented using inheritence, or for some cases, it's better to use an actual protocol declaration and ensure that classes confirm to the appropriate protocols.) A perfect example of this is that many applications written for the Mac can easily be moved over to iOS because the only major difference between the two platforms is at the user interface level, which is completely understandable given that the interface for the Mac is traditionally a large screen that the user interacts with via a keyboard and a mouse, on the other hand, the interface for iOS consists of a much smaller screen that the user touches to interactive with.

进一步阅读。 维基百科页面（属于当然！）， Apple开发者文档中的MVC ，Erik M. Buck的'Cocoa Design Patterns' / a>。

Further reading. The wikipedia page (of course!), MVC in the Apple Developer Documentation, 'Cocoa Design Patterns' by Erik M. Buck.

我试图让这个解释对所有平台，框架和语言都相当通用。在iOS开发中，MVC设计被认为是至关重要的，你必须非常努力地对抗框架以避免使用MVC。视图类（UIView，UITableView，UIAlertView，UIImageView等）和控制器类（UIViewController，UITableViewController，UINavigationController等）和其他模型类（NSString，NSDate，NSManagedObjectContext，UIImage等）之间有明显的区别。 ）。每个班级都明显属于这三个类别之一，允许代码重用，并且在您开发应用程序时具有极大的灵活性。

I've tried to keep this explanation fairly generic to all platforms, frameworks and languages. In iOS development, the MVC design is considered so paramount that you would have to work very hard against the frameworks to avoid using MVC. There is a clear distinction between the view classes (UIView, UITableView, UIAlertView, UIImageView etc.) and the controller classes (UIViewController, UITableViewController, UINavigationController etc.) and the rest of the model classes (NSString, NSDate, NSManagedObjectContext, UIImage etc.). Every class clearly resides in one of these three categories which allows for code reuse and hugely flexibility as you're developing your app.

更具体地说，与您的问题有关，您的AppDelegate将落入控制器类别类别。它可以控制应用程序的关键事件。应用程序启动时，何时退出，何时进入后台模式等。你的程序需要有一个处理这些事件要处理的地方，这就是应该实现的地方。

More specificly relating to your question, your AppDelegate will fall into the controller classes category. It provides the control over the key events of your application. When the application is launched, when it will quit, when it will enter background mode and so on. Your program needs to have a place where the thing to do at these events is handled and this is where it should be implemented.

我希望这会有所帮助。我还强烈建议在Model-View-Controller范例中查看免费的WWDC2010会话视频。

I hope this helps. I'd also strongly recommend checking out the free WWDC2010 Session Video on the Model-View-Controller paradigm.

这篇关于如何让每个班级互相交流？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！