Лучшая практика и обоснование: # импорт в .m или .h

Question

Каково обоснование размещения операторов #import в файлах .m, а не .h в Objective-C?

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

Что меня смущает, так это то, что .h должен определять интерфейс для реализации, поэтому #import будет логически переходить к файлу .h вместо .m.

Answer 1

Если вы поместите все свои #import в заголовочные файлы, то никакие два класса не могут взаимно зависеть друг от друга, потому что файл не может импортировать файл, который его импортирует. Если вы поместите #import в файл реализации, с другой стороны, проблема исчезнет.

Answer 2

В любом исходном файле вы должны #import только то, что вам нужно, чтобы сделать этот файл допустимым для компиляции. Помните, что ваши заголовки могут использоваться другими классами, поэтому вы хотите сделать их максимально легкими. Именно поэтому предпочтительно использовать @class для предварительных объявлений классов, отличных от вашего суперкласса.

Answer 3

Если интерфейс вашего класса зависит от интерфейса другого класса (т. Е. Если он является подклассом), тогда включите заголовок, в противном случае заранее объявите другой класс с помощью @class и включите заголовок интерфейса этого класса в источник зависимого класса файл.

Аргументация проста; ссылаясь только на классы в заголовке, а не импортируя весь интерфейс, вы можете определить взаимозависимые классы (т.е. классы, которые зависят друг от друга), в противном случае такая настройка невозможна, потому что произойдет рекурсивное включение файла (но Objective-C #import гарантирует, что этого не произойдет).

Answer 4

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

Answer 5

Все остальное в стороне, это также выигрыш в производительности для времени компиляции. Когда вы #import файл, это как если бы вы вставили содержимое файла в заголовок. Это еще кое-что, что компилятор должен пройти при компиляции вашего кода.

См. страницу о производительности компилятора Clang .

Обратите внимание, что предварительно скомпилированные заголовки облегчают большую часть проблемы в случае стандартных заголовков, таких как Cocoa.h.

Answer 6

Каково обоснование размещения операторов #import в файлах .m, а не .h в Objective-C?

Возможно, в одном из методов реализации вы создали локальную переменную типа класса, которую вы можете использовать только один или два раза, и вы не хотите, чтобы оператор #import загромождал ваш заголовочный файл. Или вы могли бы использовать @class в заголовке в качестве прямого объявления, и вам нужно ссылаться на этот класс в вашей реализации с помощью оператора #import.