Организация операторов #import для Objective-C / XCode

Question

После нескольких месяцев кодирования в Objective-C я полностью понимаю, когда мне нужно #import, как каскадные операторы импорта (рябь?) И когда использовать классы пересылки.Я не знаю, как агрегировать импорт, чтобы получить его внутри <> вместо кавычек (хотя, может быть, это только для фреймворков) ...

Проблема в том, что яделает огромный беспорядок.Я пришел из Java (и жесткой IDE), поэтому я просто добавляю импорт по своему усмотрению.Иногда я добавляю их в интерфейс, но, как правило, в этом нет необходимости, я просто добавляю их в верхнюю часть рассматриваемого .m.

Сегодня я начал думать: должны быть некоторые практические правила о том, как организовать этот материал.На самом деле, поскольку Objective-C является надмножеством C, существуют практические правила для всего , но я их не знаю. Как мне организовать мой импорт? В частности:

• Когда я должен импортировать в .m?
• Когда я должен импортировать в .h?
• Должен ли я создавать .h файлы только для того, чтобы их импортировать (т. Е. Заголовочные файлы, в которых есть только импорт)?Если да, какие-нибудь намеки на организацию этого?

Это всего лишь общее представление о том, что я пытаюсь выяснить.

Answer 1

Синтаксис <....> действительно только для фреймворков.Это не означает, что вы не должны создавать каркас, содержащий основную логику вашего приложения.Часто это полезно сделать, если вы:

a) Нужно обеспечить поддержку загружаемых пакетов, которые хотят вызывать аспекты логики вашего приложения (пакет связывает с каркасом, как и ваше приложение) b)Напишите несколько приложений, которые используют одну и ту же базовую логику.

Ваш вопрос несколько субъективен, и вы получите разработчиков, которые спорят обоими способами, но я придерживаюсь соглашения:

1. Никогда не импортируйте определения классовв файле .h, , если вы не подкласс его .Используйте директивы forward @class для всего в .h.
2. Импортируйте только определения классов в .m, поскольку вы обнаружите, что вам нужно использовать этот класс в реализации.

Вообще говоря, .h не нуждается в доступе к определению класса своих ivars, аргументов метода или возвращаемых значений.Нужно только знать, что это классы, что @class позволяет вам делать. нужен доступ к определению класса всего, что вы подклассируете, добавляете категорию или (очевидно) реализуете протокол для.

Answer 2

Забудьте о том, <...> для рамок или что. <...> проверяет путь поиска в системном заголовке, а "..." проверяет текущий каталог в дополнение к. Однако следует помнить, что объявление <CoreFoo/CoreFoo.h> обрабатывается на платформе Apple немного по-другому, но только в том, что касается рамок Apple: CoreFoo.framework/Headers/CoreFoo.h соответствует CoreFoo/CoreFoo.h

Answer 3

Когда импорт находится внутри <> вместо кавычек, все это означает, что вы импортируете что-то из фреймворка.Фактически, при этом импорт обычно выполняется в стиле

#import <Foundation/Foundation.h>

. Первый Foundation перед косой чертой - это имя рассматриваемой инфраструктуры, а второй - просто заголовок.файл в этой структуре.Этот заголовочный файл просто похож на

#import <Foundation/NSObjCRuntime.h>
#import <Foundation/NSArray.h>
#import <Foundation/NSAutoreleasePool.h>
...
#import <Foundation/NSURLHandle.h>

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

Для других вещей, следуя практическому правилу, чтовы хотите, чтобы материал знал как можно меньше, вы хотите поместить импорт в заголовочный файл, только если это необходимо (например, для ivar или суперкласса), но на самом деле это дело вкуса.