当前位置：文江博客话题详情

什么最能描述 Objective-C 和 Cocoa Bindings？

发布于 2024-07-14 05:40:58 字数 56 浏览 10 评论 0原文

我无法理解 Cocoa Bindings。有人可以用人类可以感知的方式向我解释这是什么意思吗？

原文

分享到QQ

分享到微博

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

发布评论

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

萤火眠眠 2024-07-21 05:40:58

Bindings 是一个将视图连接到控制器的系统，无需编写大量粘合代码即可使它们显式地相互通信。您所要做的就是在两个类*中设置属性并在 IB 中连接绑定。

传统的方法是视图有一个或多个出口与控制器对话（最通用的例子是delegate和target），并且控制器有出口与控制器对话。意见。当控制器更新模型时，它会发送（例如）[view modelChange:newModelObject]。当视图想要更新模型时，它会向其委托（控制器）发送一些委托消息，例如 NSText 的 textDidChange:。

使用绑定，您在代码中所需要做的就是在视图上实现属性并在控制器上实现属性，然后将视图的一个或多个属性公开为绑定*。然后你只需要连接绑定即可。如果它是一个 Cocoa 类，这就是小菜一碟：只需在 IB 中设置它即可。如果它是您自己的自定义类，您可能会自己编写 bind:toObject:withKeyPath:options: 消息（并不难）。

让我重申一下：使用 Bindings，您的整个粘合代码（大多数时候）是 [view bind:@"viewProperty" toObject:self withKeyPath:@"controllerProperty.modelProperty" options:options];在控制器中。其他一切都由后台的 Bindings 和 KVO 系统以及属性的访问器处理。

缺点是你必须严格遵守Cocoa Bindings的要求。这些很简单，但许多旧应用程序的设计方式不适合 Cocoa Bindings。

您必须创建真实的模型对象，而不仅仅是传递原始对象（例如，字典数组）。如果您使用 Core Data，这很简单：您的托管对象是模型对象。
您必须正确编写访问器或合成正确的访问器。例如，NSString 属性应该始终是 @property(copy)，而不是 @property(retain) （因为否则，你会发现自己保留了别人的可变字符串，这当你拿着它时它们就会发生变异）。
您必须仅通过模型对象的属性 (model.foo = bar) 或通过访问器消息 ([model setFoo:bar] >)，绝不通过直接实例变量访问。（如果您编写了自己的访问器方法，则访问器方法本身显然是例外，因为它们必须直接访问实例变量。）

有两个优点：

您可以编写全新的视图类，而无需删除大量粘合代码。您最多需要删除的是旧视图属性的一些 bind:::: 消息。如果几年后，您认为当前的视图无法扩展到应用程序即将推出的功能，那么您可以灵活地将其删除并以最小的痛苦重新开始。
更重要的是，您需要阅读的代码越少，就越容易阅读。

*并且，根据文档，实现 KVO 观察方法在视图类中，但我实际上从未这样做过。我提交了文档错误。

添加于2009-03-07：啊，找到了一个引用。 “NSView 子类可以通过为每个属性调用类方法 ExposureBinding: 来将其他符合键值编码/键值观察的属性公开为绑定。” -NSKeyValueBindingCreation 所以你不应该需要实现一个KVO观察方法。

Bindings is a system for connecting your views to your controllers without writing a lot of glue code to make them explicitly talk to each other. All you have to do is set up properties in both classes* and hook up the binding in IB.

The traditional approach is that the view has one or more outlets to talk to the controller (the most generic examples being delegate and target) and the controller has outlets to talk to the views. When the controller updates the model, it sends (for example) [view modelChange:newModelObject]. When the view wants to update the model, it sends some delegate message to its delegate (the controller), such as NSText's textDidChange:.

With Bindings, all you have to do in code is implement properties on the view and properties on the controller, then expose one or more properties of the view as bindings*. Then you only need to hook up the binding. If it's a Cocoa class, this is cake: just set it up in IB. If it's a custom class of your own, you'll probably write the bind:toObject:withKeyPath:options: message yourself (not much harder).

Let me restate that: With Bindings, your entire glue code (most of the time) is [view bind:@"viewProperty" toObject:self withKeyPath:@"controllerProperty.modelProperty" options:options]; in the controller. Everything else is handled by the Bindings and KVO systems behind the scenes, and by your properties' accessors.

The disadvantage is that you must strictly conform to Cocoa Bindings' requirements. These are simple, but a lot of older applications are designed in a way that doesn't fit Cocoa Bindings.

You must create real model objects, not just pass primitive objects (e.g., arrays of dictionaries) around. If you're using Core Data, this is easy: your managed objects are model objects.
You must either write your accessors correctly or synthesize the correct accessors. For example, an NSString property should always be @property(copy), never @property(retain) (because otherwise, you will find yourself retaining someone else's mutable string, which they will then mutate while you're holding it).
You must only change properties of your model objects by their properties (model.foo = bar) or by accessor messages ([model setFoo:bar]), never by direct instance variable access. (Obvious exception for accessor methods themselves, if you've written your own, because they must access the instance variable directly.)

There are two advantages:

You can write a brand new view class without having to rip out a lot of glue code. The most you'll have to delete is some bind:::: messages for the old view's properties. If, a couple of years down the road, you decide that your current view just can't scale to your application's forthcoming capabilities, this gives you the flexibility to rip it out and start afresh with the minimum of pain.
More importantly, the less code you have to read, the easier it is to read it.

*And, according to the documentation, implement a KVO observation method in the view class, but I've never actually had to do this. I filed a documentation bug.

Added 2009-03-07: Ah, found a citation. “NSView subclasses can expose additional key-value-coding/key-value-observing compliant properties as bindings by calling the class method exposeBinding: for each of the properties.” —NSKeyValueBindingCreation So you shouldn't need to implement a KVO observation method.

回复收藏 0 原文

番薯 2024-07-21 05:40:58

之前的答案非常全面且很好，我只是想添加一个答案来解释它的核心内容，而不具体涉及 Cocoa 或 Objective-C。这是因为这个概念本身与语言无关，尽管像 Objective-C 这样的动态语言比 C++ 这样的静态语言更容易实现。

示例

假设您有两个对象 M 和 V。 M 有方法：

setX(int x);
setY(int y);
int getX();
int getY();

而 V 有方法：

setA(int x);
setB(int y);
int getA();
int getB();

看待这个问题的一种方式是 M 具有属性 x 和y 和 V 具有属性 a 和 b。您希望属性 x 的更改会导致属性 b 的更改，并且 y 的更改会导致 a< 的更改/强>。

通过改变属性x，我们的意思是：

M.setX(10)

之前的位置

M.getX() != 10

所以我们希望在M上调用setX来调用setA 在V上。

绑定允许您说对象 V 上的属性 b 绑定到对象 M 上的属性 x。然后这个更新是自动处理的。作为编码员，您不必编写代码来检查 x 是否已更改，然后对 V 调用 setB。绑定会自动处理这个问题。

摘要

绑定允许您将两个不同对象上存在的两个属性绑定在一起，以便更改其中一个属性的值会导致另一个对象中的依赖属性更改为相同的值。

Previous answer is very comperhensive and good, I'd just thought I'd add an answer explains what it is at its core without involving Cocoa or Objective-C specifically. That is because the concept itself is language agnostic although dynamic languages like Objective-C makes it a lot easier than more static language like C++.

Example

Say you have two objects M and V. M has methods:

setX(int x);
setY(int y);
int getX();
int getY();

While V has methods:

setA(int x);
setB(int y);
int getA();
int getB();

One way of looking at this is that M has properties x and y and V has properties a and b. You want a change of property x to cause a change in property b and a change in y to cause a change in a.

By change in property x we mean e.g.:

M.setX(10)

where previously

M.getX() != 10

So we want a call of setX on M to cause a call to setA on V.

What bindings allow you to say is that property b on object V is bound to property x on object M. And then this updating is handled automatically. You as a coder don't have to write code that checks if x is changed and then call setB on V. Bindings takes care of this automatically.

Summary

Bindings allows you to bind two properties together that exist on two different objects, so that changing the value of one of the properties causes the dependant property in the other object to change to the same value.

回复收藏 0 原文

~没有更多了~