Это зависит от ваших предпочтений.
Я предпочитаю писать это в коде.
- Я могу повторно использовать код.
- Использование XIB / NIB обычно нарушает правило одного определения (если вы делаете какую-либо настройку).
- Обслуживание XIB / NIB часто более утомительно и подвержено ошибкам (ODR). Мне очень не нравится поддерживать стили кнопок (пример) для каждой кнопки.
- циклические ссылки более вероятны.
- Экземпляры кода / объектов / ib часто менее пригодны для повторного использования / модульные. Хотя я из тех, кто избегает объекта пользовательского интерфейса, который может делать все.
- Отложенный / неоднозначный порядок инициализации создает довольно пугающее состояние для клиентов, которые никогда не должны предполагать, что объект готов к использованию или полностью инициализирован (если вы не предпочитаете поддерживать эти проверки, что является хорошим способом тратить время).
- Если важна производительность, угадайте, что быстрее?
- Управление ресурсами против линкера ... серьезно, я написал подпрограммы и тесты для проверки существования перьев в комплекте.
IB отлично подходит для создания прототипов и просмотра возможностей и внешнего вида объектов (я не графический дизайнер), хотя I думаю, что проще всего написать его в коде, если прототип существует, если у вас есть намерение поддержания или повторного использования.
Моя рекомендация: писать многократно используемые и стабильные библиотеки кода и использовать IB в первую очередь для создания прототипов и одноразовых.
Ответы:
Sbrocket: Мне любопытно, почему вы утверждаете, что циклические ссылки более вероятны в результате использования NIB.
Привет Sbrocket: Начну с того, что я использую Interface Builder со времен Project Builder (предшественник Xcode).
Отсутствие надежного структурированного владения, идентификации и инициализации. Я не хочу, чтобы ivars были соединениями IB, потому что это затрудняет использование многих классов за пределами «текущего контекста». Другими словами, он связывает код с ресурсом (чаще, чем в идеале). Поскольку вы не можете определить порядок инициализации или определить инициализаторы или дополнительные аргументы инициализации в IB, вы должны сообщить объектам друг о друге, создавая циклические зависимости и ссылки.
Sbrocket: или почему ленивая инициализация (при условии, что это именно то, на что вы ссылаетесь) настолько страшна, когда ее относительно легко (или на самом деле во многих случаях автоматически) обеспечить инициализацию и подключение объекта.
Re: страшно
Я не говорил о ленивой инициализации. Я говорил об отложенном и неоднозначном порядке инициализации.
Инициализация пера полуупорядочена. Фактический порядок / процесс может варьироваться, и это не может быть надежно использовано в многократно используемых интроспективных программах ... опять же, вы в конечном итоге написали бы слишком много кода, который хрупок, невозможен для повторного использования, никогда не может быть гарантированно вести себя предсказуемо и должен всегда проверять состояние (еще одна запись для круговой зависимости). Если это не разовая реализация, зачем беспокоиться об осложнениях?
Этот подход к программированию хаотичен, и реализации должны (в свою очередь) быть готовы обработать что-либо в любое время. Одно дело оградить себя от сбоев, но написать защитный код производственного уровня в этом контексте ... никак.
Гораздо проще написать непротиворечивую программу, инициализация которой определяет достоверность в контексте, и реализации могут знать (если она инициализирована), что объект обычно готов к использованию. Особый случай сложность сведена к минимуму. Многие такие проекты разваливаются по мере увеличения сложности программы, в то время как авторы библиотек добавляют слои к слоям «защитных мер» просто для того, чтобы поддерживать движение шестерен - многопоточность - отличный вход для таких гейзенгов. Ненужные двусмысленности нежелательны в повторно используемом коде уровня производства; людям не нужно перекрестно ссылаться на все особые случаи программы, а сложности, связанные с определенным поведением и особыми случаями, только распространяются или игнорируются (при условии, что они должным образом отслеживаются и документируются, что является более сложным делом, чем правильная запись с самого начала ). Я думаю, что мы все можем согласиться с тем, что следует избегать обременительных интерфейсов и реализаций.
Sbrocket: Мне также было бы интересно увидеть некоторые точные цифры, которые показывают, что загрузка NIB медленнее - конечно, на первый взгляд это может иметь смысл, но мы всегда такие плохие предикторы узких мест производительности без некоторых жесткое тестирование.
Я никогда не говорил (явно), что это было медленнее :) 1060 *
Ладно, если серьезно, разархивирование NIB было (для меня) удивительно медленным процессом, хотя наши представления о медленном и разархивирующем времени могут сильно различаться.
Пример: у меня было приложение на основе документа, и загрузка пера была в несколько раз медленнее, чем загрузка документа, когда размеры документа были в несколько раз больше размера пера. Перемещение реализации в коде значительно ускорило процесс. Как только он был в коде, и у меня был контроль порядка инициализации, я удалил несколько сложностей с многопоточностью (контрольные точки, блокировки, записи условий гонки и т. Д.), Что сделало загрузку документов еще быстрее.
Теперь, когда у вас есть четкий ответ, я напомню, что у вас есть все инструменты, необходимые для измерения производительности.
Помните, что анализ производительности и улучшения изучены .