什么描述objective-C和Cocoa Bindings最好？ [英] What describes objective-C and Cocoa Bindings best?

问题描述

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

解决方案

绑定是一个系统，视图到你的控制器没有写很多胶水代码，使他们明确地互相交谈。所有你需要做的是在两个类*中设置属性，并在IB中绑定绑定。

传统的方法是视图有一个或多个outlet到控制器（最通用的例子是 delegate 和 target ），并且控制器具有与视图交谈的插座。当控制器更新模型时，它发送（例如） [view modelChange：newModelObject] 。当视图要更新模型时，它会向其委托（控制器）发送一些委托消息，例如NSText的 textDidChange：。

对于Bindings，你需要在代码中对视图和控制器上的属性实现属性，然后将视图的一个或多个属性暴露为绑定*。然后你只需要挂接绑定。如果它是一个Cocoa类，这是蛋糕：只是设置在IB。如果它是你自己的自定义类，你可能会写自己的 bind：toObject：withKeyPath：options：消息。让我重申一下：使用Bindings，你的整个粘合代码（大部分时间）是 [view bind：@viewPropertytoObject：self withKeyPath：@controllerProperty .modelPropertyoptions：options]; 。一切都由后台的Bindings和KVO系统以及属性的访问器来处理。

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

• 您必须创建真正的模型对象，而不仅仅是传递原始对象（例如，字典数组）。如果您使用Core Data，这很容易：您的托管对象是模型对象。


• 您必须正确写入您的访问器或合成正确的访问器。例如，NSString属性应始终为 @property（copy），从不 @property（retain） ，你会发现自己保留了其他人的可变字符串，然后他们会在你握住它的时候改变）。


• 你必须更改你的模型的属性对象的属性（ model.foo = bar ）或者通过访问器消息（ [model setFoo：bar] 从不通过直接实例变量访问。 （如果您已经编写自己的方法，那么访问器方法本身就是明显的例外，因为他们必须直接访问实例变量。）

有两个优点：

• 您可以编写一个全新的视图类，而不必撕掉很多胶水代码。您最需要删除的是旧视图属性的一些 bind :::: 消息。如果在几年后，你决定你的当前视图不能扩展到你的应用程序的即将到来的功能，这让你有弹性，撕裂出来，以最小的痛苦重新开始。


• 更重要的是，您阅读的代码越少，阅读越容易。

，根据文档，实施 KVO观察方法在视图类，但我从来没有实际上必须这样做。我提交了文档错误。

Added 2009-03-07：啊，发现了一个引文。 NSView子类可以通过调用类方法exposeBinding：为每个属性公开附加的键值编码/键值观察兼容属性作为绑定。 - NSKeyValueBindingCreation 所以你不需要实现KVO观察方法。

I have trouble understanding Cocoa Bindings. Can someone explain me what this is all about, in an way that is humanly perceivable?

解决方案

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.

这篇关于什么描述objective-C和Cocoa Bindings最好？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！