Использование «внешнего объекта» в построителе интерфейса и модульности

Question

Это вопрос о передовой практике.

У меня есть приложение, которое использует стандартный контроллер вкладок iOS.

Одна из вещей, которые я хотел бы сделать, это разделить XIB на отдельные файлы. Я могу добиться этого, указав дочерний XIB в разделе «Имя NIB» для каждого контроллера вкладок. Пока все хорошо.

В этом приложении у меня есть объект, который используется практически всеми UIViewControllers (например, обеспечивает вызовы веб-службы). Давайте назовем это MyServices.

В одном решении XIB я могу перетащить объект в список объектов, установить тип «MyServices». Я могу объявить в каждом ViewController IBOutlet типа MyServices * и соединить их вместе. Это хорошо работает.

Однако, если я перенесу свое представление в отдельную XIB, любые контроллеры, расположенные ниже по стеку, которым требуется доступ к объекту MyServices, будут везучими, потому что объект больше не существует в этой XIB для выполнения подключения.

Что я ожидал сделать, так это объявить «внешний объект» и подключиться к нему. Но я не вижу, как я «передаю» объект MyServices в «родительской» XIB как «внешний» объект в дочерней XIB.

Это просто не поддерживается в IB? Какая лучшая альтернатива?

Я не смог указать имя XIB в контроллере и, возможно, программно создать его во время выполнения (предположительно, с помощью какого-то кода loadFromNib, объявляющего словарь для предоставления внешнего объекта). Это означает, что контроллер, который делает это, должен знать о MyServices, даже если он не использует его напрямую.

В качестве альтернативы, у меня мог бы быть «dataProvider» в каждом UIViewController, поэтому вместо установки MyServices непосредственно в качестве IBOutlet он мог бы делать [dataProvider getServices]. Опять же, придется подключиться к чему-то, что может сделать это - что ограничивает возможности разрыва XIB. И это кажется немного ненужно многословным ..

Какая лучшая практика здесь?

Answer 1

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

Могу ли я использовать Interface Builder для внедрения зависимостей в несколько перьев? задает очень похожий вопрос к вам, также без реального решения.

В Как настроить прокси-объект в NIB основного приложения? автор также отказывается от идеи использовать Interface Builder в качестве инструмента внедрения зависимостей.

Так что я бы предположил, что мы, иммигранты на Яве, стучим нашими головами по невидимым стенам здесь. Метафоры, которые мы используем для формирования кода в наших головах (и качества кода, которые мы оцениваем и ассоциируем с качеством), не применяются к Objective-C, как есть. Это может быть потому, что мы не знакомы с идиомами Obj-C. Или, может быть, мы имеем дело с различными эволюционными этапами развития языка и сообщества (например, см. Ошеломляющую незрелость практики TDD в Obj-C). Лично я не видел много лучших практик , описанных в мире Obj-C за 9 месяцев, когда я серьезно с этим справляюсь.