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

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

Задача связи сводится к способности одного объекта видеть другой. Например, объект Manny должен быть в состоянии неоднократно и надежно находить объект Jack в течение длительного периода времени, чтобы иметь возможность посылать ему сообщения. Одно из очевидных решений этой задачи состоит в том, чтобы объявить переменную экземпляра объекта Manny и присвоить ей в качестве значения объект Jack. Такое решение оказывается пригодным особенно в тех случаях, когда объекты Manny и Jack разделяют некоторые общие обязанности или снабжают друг друга определенными функциональными возможностями. Объект приложения и его делегат, табличное представление и его источник данных, контроллер и представление, которым он управляет, — все это примеры, в которых один объект должен иметь переменную своего экземпляра, указывающую на другой объект.

Это совсем не означает, что объект Manny должен утверждать право на владение объектом Jack, как того требует стратегия управления памятью (см. главу 12). Как правило, объект не сохраняет свой делегат или источник данных. Аналогично объект, реализующий шаблон “цель-действие”, например, объект класса UlControl, не сохраняет свою цель. Однако тогда объект Manny должен быть готовым к тому, что предполагаемая им ссылка на объект Jack окажется пустой, а следовательно, необходимо принять меры к тому, чтобы она не превратилась в висячий указатель (правда, это маловероятно, если действует механизм ARC). С другой стороны, контроллер представления оказывается бесполезным в отсутствие представления, которым он должен управлять. Получив такое представление, он сохранит его, освободив лишь тогда, как сам прекратит свое существование. Возможны и другие подобные ситуации, в которых требуется, чтобы один объект владел другим объектом.

Объекты могут также устанавливать двухстороннюю связь, не сохраняя постоянные ссылки друг на друга в переменных экземпляра. Например, объект Manny может послать объекту Jack сообщение, где одним из параметров является ссылка на объект Manny. Это может быть лишь форма идентификации или приглашения объекта Jack послать сообщение обратно объекту Manny, если объекту Jack требуются дополнительные сведения на время выполнения полученного им метода. Опять же это общий шаблон. Параметром делегата сообщения

textFieldShouldBeginEditing: служит ссылка на объект типа UITextField, пославший это сообщение. Первым параметром сообщения “цель-действие” является ссылка на отправителя этого сообщения. Таким образом, объект Manny делает себя сразу же видимым для объекта Jack, которому совсем не обязательно сохранять объект Manny, чтобы избежать возникновения цикла сохранения.

Как же объекту Manny получить сначала ссылку на объект Jack? Это непростой вопрос. Искусство программирования для операционной системы iOS в частности и объектно-ориен-тированного программирования вообще состоит главным образом в том, чтобы организовать получение одним объектом ссылки на другой объект. (Этот вопрос обсуждался также в главе 5.) В каждом отдельном случае решать данную задачу приходится иначе. Тем не менее появился ряд общих шаблонов, упрощающих ее решение и вкратце рассматриваемых в этой главе.

Имеются также способы, позволяющие объекту Manny послать сообщение, которое объект Jack получит, даже если оно не адресуется этому объекту непосредственно, или ничего неизвестно, или вообще безразлично, что собой представляет объект Jack. Примерами тому служат уведомления и механизм наблюдения за значениями по ключам, которые также обсуждаются в этой главе. В завершение главы рассматривается следующий важный вопрос: какие виды объектов должны видеть друг друга в общей области действия типичной прикладной программы для операционной системы iOS.

 

 

 

• Назад
• Вперёд