Что лучше всего описывает цель C и какао? - PullRequest
Новая
       10

Что лучше всего описывает цель C и какао?

21 голосов
/ 27 февраля 2009

У меня проблемы с пониманием привязки какао. Может ли кто-нибудь объяснить мне, что это такое, в человеческом восприятии?

Ответы [ 2 ]

29 голосов
/ 27 февраля 2009

Привязки - это система для соединения ваших представлений с вашими контроллерами без написания большого количества связующего кода, чтобы они явно общались друг с другом. Все, что вам нужно сделать, это настроить свойства в обоих классах * и подключить привязку в IB.

Традиционный подход состоит в том, что у представления есть один или несколько выходов для связи с контроллером (наиболее распространенными примерами являются delegate и target), а у контроллера есть выходы для связи с представлениями. Когда контроллер обновляет модель, он отправляет (например) [view modelChange:newModelObject]. Когда представление хочет обновить модель, оно отправляет некоторое сообщение делегата своему делегату (контроллеру), например, textDidChange:.

в NSText.

При использовании привязок все, что вам нужно сделать в коде, - это реализовать свойства представления и свойства контроллера, а затем представить одно или несколько свойств представления в качестве привязок *. Тогда вам нужно только подключить привязку. Если это класс Какао, то это торт: просто установите его в IB. Если это ваш собственный класс, вы, вероятно, сами напишите сообщение bind:toObject:withKeyPath:options: (не намного сложнее).

Позвольте мне повторить, что: При использовании Bindings весь ваш клейкий код (в большинстве случаев) находится в контроллере [view bind:@"viewProperty" toObject:self withKeyPath:@"controllerProperty.modelProperty" options:options];. Все остальное обрабатывается закулисными системами и системами KVO, а также средствами доступа к вашим свойствам.

Недостатком является то, что вы должны строго соблюдать требования Cocoa Bindings. Это простые, но многие старые приложения разработаны так, чтобы не соответствовать привязкам Cocoa.

  • Вы должны создавать реальные объекты моделей, а не просто передавать примитивные объекты (например, массивы словарей) вокруг. Если вы используете базовые данные, это легко: ваши управляемые объекты являются объектами модели.
  • Вы должны либо написать свои аксессоры правильно, либо синтезировать правильные аксессоры. Например, свойство NSString всегда должно быть @property(copy), а не @property(retain) (потому что в противном случае вы обнаружите, что сохраняете чужую изменяемую строку, которую они затем будут мутировать, пока вы ее держите).
  • Вы должны только изменять свойства объектов вашей модели по их свойствам (model.foo = bar) или сообщениям доступа ([model setFoo:bar]), но не по прямому доступу к переменной экземпляра. (Очевидное исключение для самих методов доступа, если вы написали свои собственные, потому что они должны обращаться к переменной экземпляра напрямую.)

Есть два преимущества:

  • Вы можете написать новый класс представлений, не тратя много кода. Самое большее, что вам нужно будет удалить - это несколько bind:::: сообщений для свойств старого представления. Если, спустя пару лет, вы решите, что ваше текущее представление просто не может масштабироваться до будущих возможностей вашего приложения, это дает вам гибкость, чтобы вырвать его и начать заново с минимумом боли.
  • Что еще более важно, чем меньше кода вы должны прочитать, тем легче его прочитать.

* И, согласно документации, реализовать метод наблюдения KVO в классе представления, но мне никогда не приходилось это делать. Я подал ошибка документации .

Добавлено 2009-03-07: Ах, нашел цитату. «Подклассы NSView могут предоставлять дополнительные свойства, соответствующие кодированию значений ключа / наблюдения значения ключа, в качестве привязок, вызывая метод класса exposeBinding: для каждого из свойств». реализовать метод наблюдения КВО.

16 голосов
/ 08 марта 2009

Предыдущий ответ очень всеобъемлющий и хороший, я просто подумал, что добавлю ответ, объясняющий, в чем его суть, без особого участия какао или Objective-C. Это потому, что сама концепция не зависит от языка, хотя динамические языки, такие как Objective-C, делают ее lot проще, чем более статичный язык, такой как 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 мы подразумеваем, например ,::1045* 

M.setX(10)

где ранее 

M.getX() != 10

Итак, мы хотим, чтобы вызов setX на M вызывал вызов setA на V .

Привязки позволяют вам сказать, что свойство b объекта V связано со свойством x объекта M . И тогда это обновление обрабатывается автоматически. Вам, как программисту, не нужно писать код, который проверяет, изменилось ли x , а затем вызывать setB on V . Bindings позаботится об этом автоматически.

Резюме

Привязки позволяют связывать два свойства вместе, которые существуют на двух разных объектах, так что изменение значения одного из свойств приводит к тому, что зависимое свойство в другом объекте изменяется на одно и то же значение.

...