避免在基于文档的 Cocoa 应用程序中耦合?

发布于 2024-12-28 01:41:22 字数 771 浏览 2 评论 0原文

我是 Mac 编程新手,正在开发基于文档的应用程序。

我的 NSDocument 子类创建了一个 NSWindowController 子类。该窗口控制器还创建两个 NSViewController 子类。

有时,NSViewController 的视图之一的更改需要通知 NSDocument 和/或主模型类。此外,模型的更改需要通知每个/某些视图。

我的问题是:没有(或最小)耦合的最佳方法是什么?我知道有多种选择,但我不确定哪一种最适合我的应用程序,因为我不是编程新手,而是 Cocoa 新手,尤其是 NSDocument

  • KVO。看起来不错并且易于实现,但我不喜欢不明确通知观察者有关更改的想法(据我所知, self.someProperty = newValue 会自动通知观察者),并且不喜欢这样的事实:您必须注册可能会随时更改的属性名称。

  • 通知。我知道它们是什么,并且我已经在 iOS 上使用过它们。但我在某处读到,不能保证它们会立即发送给观察员。这是真的吗?如果不是,您认为它们是基于文档的应用程序的好方法吗?

  • 代表。是的,在正常情况下(或者我通常看到的),一个类有一个代表。但是创建一个委托数组也可以(刚刚测试过)。我在这里看到的问题是,每次我需要通知委托时,我都必须循环遍历它们,确保它们响应方法,然后调用该方法。

我还缺少其他选择吗?

I'm new to Mac programming and I'm working on a document-based application.

My NSDocument subclass creates a NSWindowController subclass. This window controller creates two NSViewController subclasses as well.

Sometimes, a change in one of the views of a NSViewController needs to notify the NSDocument and/or the main model class. Also, a change in the model needs to be notified to every/some view(s).

My question is: what is the best approach so that there is no (or minimum) coupling? I know there are several choices, but I'm not sure which one suits best for my application as I'm newbie not to programming but to Cocoa and especially NSDocument:

  • KVO. Looks nice and easy to implement, but I don't like the idea of not explicitly notifying the observer(s) about a change (AFAIK, self.someProperty = newValue does automagically notify observers), and don't like the fact that you have to register to property names which could change in time.

  • Notifications. I know what they are and I've used them for iOS. But I've read somewhere that they are not guaranteed to be sent immediately to observers. Is it true? If not, do you see them as a good approach for a document-based app?

  • Delegates. Yes, under normal conditions (or what I've usually seen), a class has one delegate. But creating an array of delegates works as well (just tested it). The problem I see here is that every time I need to notify the delegates I have to loop through them, make sure they respond to a method, and call that method.

Are there any other alternatives I'm missing?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

柒七 2025-01-04 01:41:22

控制器类的 KVO 是在模型与其视图之间进行耦合的最常见方法。事实上,Cocoa Bindings 的目的主要是消除控制器层中的代码,它是基于 KVO 的。确实,KVO/KVC 依赖于属性名称,如果这些名称发生变化,您将必须更改连接视图的绑定或 KVO 设置。然而,让你的视图完全不了解底层模型的细节通常是不可行的,所以我不认为这是一个问题。

我的建议是尽可能使用 Cocoa Binding,因为它们消除了很多粘合代码。在无法使用它们的地方,您的控制器(MVC 中的中间层)应该使用 KVO 来观察模型更改并更新相应的视图。视图中的更改可以通过控制器的属性访问器和/或 KVC 传递回模型。

KVO by a controller class is the most common way to do coupling between a model and its view(s). In fact, Cocoa Bindings, which are intended to mostly eliminate code in the controller layer, are based on KVO. It is true that KVO/KVC relies on property names, and that if those change, you'll have to change the bindings or KVO setup connecting your view. However, it's not usually feasible to make your views completely unaware of the underlying model specifics, so I don't see this as a problem.

My recommendation would be to use Cocoa Binding where you can, as they eliminate a lot of glue code. In places where they can't be used, your controllers (the middle layer in MVC) should use KVO to observe model changes and update the appropriate views. Changes in the views can be passed back to the model via property accessors and/or KVC by the controllers.

浮华 2025-01-04 01:41:22

是的,在正常情况下(或者我通常看到的),一个类有
一名代表。但是创建一个委托数组也可以(只是
测试过)。

委托通常用于修改委托对象的行为。应用程序委托就是一个很好的例子:NSApplication 本身并不是很有趣;它依靠其委托来定义应用程序的有趣行为。如果各个委托相互冲突,让多个委托都尝试修改单个对象的行为可能会出现问题。如果代表不同意怎么办?

在 Cocoa 中有些情况下,一个类使用多个委托,但每个委托都有一个单独的角色。例如,NSTableView 同时具有委托和数据源,但两者实际上都是某种委托。

我在这里看到的问题是,每次我需要通知
代表们我必须循环浏览他们,确保他们响应
方法,并调用该方法。

这并不难解决。例如,您可以创建一个 NSInitation 来封装该调用,然后将该调用发送给每个“委托”。但是,如果您这样做,您几乎就重新发明了通知系统。如果您需要通过多个代表提案获得的一对多通信,那么使用通知或 KVO 可能会更好。

Yes, under normal conditions (or what I've usually seen), a class has
one delegate. But creating an array of delegates works as well (just
tested it).

Delegates are often used to modify the behavior of the delegating object. An application delegate is a good example: NSApplication by itself isn't very interesting; it relies on its delegate to define the interesting behavior of the application. Having multiple delegates all trying to modify the behavior of a single object could be a problem if the various delegates conflict with each other. What do you do if the delegates disagree?

There are some cases in Cocoa where a class uses more than one delegate, but each one has a separate role. For example, NSTableView has both a delegate and a data source, but both are really delegates of a sort.

The problem I see here is that every time I need to notify the
delegates I have to loop through them, make sure they respond to a
method, and call that method.

That's not hard to solve. For example, you could create an NSInvocation to encapsulate the call, and then send the invocation to each "delegate." However, if you do that you'll have nearly reinvented the notification system. If you need the one-to-many communication that you'd get with your multiple delegates proposal, you'll probably be better off using notifications or KVO.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文