Я размышлял над этим вопросом какое-то время...
С одной стороны, Interface Builder предлагает очень простой способ разработки интерфейса и подключения элементов к объектам в коде.
С другой стороны, в больших проектах интерфейс Builder становится проблемой для поддержки.
Приветствуются любые предложения.
Я когда-то очень сильно против использования Interface Builder в своих собственных проектах. Это было связано с рядом факторов. Сначала я начал работать с инструментами Xcode, когда iPhone SDK вернулся в бета-версию (примерно в марте 2008 года), и поскольку я не пришел с фона Mac Cocoa, я был несколько не знаком с его использованием. Это не было основным фактором в моем первоначальном отказе от разработки IB для iPhone, хотя - интерфейс Builder для разработки iPhone во время первоначальной бета-версии iPhone SDK действительно сосал, и было больно использовать.
Тем не менее, история сильно отличается от сегодняшнего iPhone SDK. Несмотря на то, что все еще есть некоторые неприятные ошибки IB, я сделал почти полное 180-е с моим отношением к использованию Interface Builder. Чаще всего это хорошая идея использовать интерфейс Builder в ваших проектах, я нашел. Теперь это отличный инструмент, и вы должны воспользоваться им.
Теперь, не поймите меня неправильно - я все еще твердо в лагере, который считает, что вы должны реализовать что-либо, которое вы делаете в Interface Builder, используя только код, и я думаю, что могу сделать это бесценно. Не используйте Interface Builder в качестве костыля - в конце концов вы только повредите себе (и свою производительность или качество своих продуктов). В то время как тонкости перетаскивания IB отлично подходят для 90% того, что вам нужно будет делать, когда у вас есть что-то обычное для реализации, которое может быть сделано только в коде, вы либо пожелаете, чтобы вы следовали или были благодарны за этим советом. Мне посчастливилось ненавидеть IB достаточно долго, чтобы научить себя тому, как делать все в одном коде, а затем применить это знание к IB.
Edit:
Чтобы устранить недостаток повторного использования (воспринимаемый или реальный) с помощью NIB по сравнению с кодом... вы не будете внедрять что-то, что должно быть сильно использовано в интерфейсе Builder, по всей вероятности. Вы не можете сделать собственный контроль или просмотр в IB, так что это исключено, и в большинстве случаев вы будете внедрять подкласс класса контроля, который построен для решения конкретной задачи. Конечно, вы всегда должны стремиться сделать свой код и связанные с ним ресурсы максимально возможными. Это может включать конструктивные соображения, чтобы убедиться, что вы не дублируете подклассы контроллера просмотра, которые очень похожи.
Использование строителей освобождает вас от кода, который вам в противном случае нужно было бы поддерживать, и тем меньше вам нужно было поддерживать лучше.
Макеты, созданные IB, требуют некоторого обслуживания, но это стандартный инструмент с собственной документацией и собственной онлайн-поддержкой (форумы, списки и т.д.). Если кому-то еще нужно перепрыгнуть в ваш код, вы можете фактически гарантировать, что у них есть опыт работы с IB, но не обязательно ваш особый стиль построения макета.
Это зависит от ваших предпочтений.
Я предпочитаю писать его в коде.
IB отлично подходит для прототипирования и просмотра возможностей и возможностей объекта (я не являюсь графическим дизайнером), хотя я считаю, что проще всего написать его в коде, как только прототип существует, если у вас есть намерение его поддерживать или повторно использовать.
Моя рекомендация: Напишите многократно используемые и стабильные библиотеки кода и используйте IB в первую очередь для прототипов и одноразовых программ.
Ответы:
Sbrocket: Мне любопытно, почему вы утверждаете, что круговые ссылки чаще возникают в результате использования NIB.
Привет Sbrocket: Я начну с того, что я использовал интерфейс Builder со времен Проектного Строителя (предшественник Xcode).
Отсутствие надежной структурированной собственности, идентификации и инициализации. Я не хочу, чтобы ivars были IB-соединениями, потому что это затрудняет использование многих классов за пределами "текущего контекста", другими словами, он связывает код с ресурсом (чаще, чем идеально). Поскольку вы не можете определить порядок инициализации или определить инициализаторы или дополнительные аргументы инициализации в IB, вы должны затем сообщать об этом друг другу, создавая круговые зависимости и ссылки.
Sbrocket: или почему ленивая инициализация (предполагая, что на самом деле то, о чем вы говорите) настолько страшна, когда ее относительно легко (или фактически автоматическое во многих случаях) гарантировать, что объект инициализирован и подключен.
Re: страшно Я не говорил о ленивой инициализации. Я говорил об отложенном и неоднозначном порядке инициализации.
Инициализация ниба является полуупорядоченной. Фактический порядок/процесс может отличаться, и это нельзя надежно использовать в многократно используемых интроспективных программах... опять же, вы в конечном итоге пишете слишком много кода, который хрупкий, невозможно повторно использовать, никогда не может быть уверен, что он будет вести себя предсказуемо и должен всегда проверяйте состояние (еще одна запись для круговой зависимости). Если это не одноразовая реализация, зачем беспокоиться об осложнениях?
Этот подход к программированию хаотичен, и реализации должны (в свою очередь) быть готовыми к тому, чтобы обращаться с чем угодно в любое время. Одно дело охранять себя от сбоев, но писать защитный код уровня производства в этом контексте... никак.
Гораздо проще написать согласованную программу, инициализация которой определяет справедливость в контексте, которую реализации могут знать (если они инициализированы), что объект обычно готов к использованию. Сложность по специальному случаю сводится к минимуму. Много таких конструкций разваливаются по мере увеличения сложности программы, в то время как библиотечные писатели добавляют слои по слоям "защитных мер" только для того, чтобы держать шестерни движущимися - потоки - отличная запись для таких гейзенбергов. Ненужные двусмысленности нежелательны в коде кода уровня многоразового использования; людям не нужно перекрестно ссылаться на все специальные случаи программы, а сложность в отношении определенного поведения и особых случаев распространяется только или игнорируется (при условии, что они надлежащим образом отслеживаются и документируются, что представляет собой более сложное усилие, чем собственно написание с самого начала). Я думаю, мы все можем согласиться с тем, что следует избегать обременительных интерфейсов и реализаций.
Sbrocket: Мне также было бы интересно увидеть некоторые жесткие цифры, которые показывают, что загрузка NIB медленнее - конечно, казалось бы, это было бы на первый взгляд, но мы всегда являемся такими плохими предсказателями узких мест производительности, жесткое тестирование.
Я никогда не говорил (явно), что он был медленнее:)
Хорошо, с серьезностью, unarchiving NIB был для меня неожиданно медленным процессом, хотя наши идеи медленного и разобщающего времени могут сильно различаться.
Пример. У меня было приложение на основе документов, а загрузка nib была в несколько раз медленнее, чем загрузка документа, когда размеры документов были в несколько раз меньше размера ниб. Перемещение реализации в код делало процесс намного быстрее. После того, как он был на коде, и у меня был контроль за порядком инициализации, я удалил несколько сложностей многопоточности (контрольные точки, блокировки, записи состояния гонки и т.д.), Что еще более ускорило загрузку документа.
Теперь, когда у вас есть явный ответ, напомню, что у вас есть все инструменты, необходимые для измерения производительности.
Помните, что анализ производительности и улучшения изучены.
Конструктор интерфейсов отлично подходит для определенного уровня сложности. Для вещей, более или менее сложных, я предпочел бы сделать это в коде.
Если у вас есть интерфейс, который не будет использоваться более чем одним способом, он содержит несколько, но не много элементов, и не нуждается в каком-либо сложном макете, чем IB.
В долгосрочной перспективе я почти никогда не использую IB. Такова же природа проектов, в которых я работаю, как личные предпочтения. Есть определенно некоторые интерфейсы, над которыми я бы направлялся прямо в IB, но мне не нужно было создавать какое-то из них через некоторое время.