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

Это вопрос лучших практик.

У меня есть приложение, которое использует стандартный контроллер вкладок 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 могут быть разбиты. И это кажется немного ненужным многословным.

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

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

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

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

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