Процесс компиляции разбивается на разные фазы, и директивы #import интерпретируются задолго до того, как произойдет какая-либо связь.
Когда вы передаете файлы кода (.c, .m) вашему компилятору, он будет пытаться сгенерировать из него файл объекта кода (.o); это двоичное представление вашего кода. Этот файл еще не исполняется, потому что ему нужно больше информации. Особенно, это не связано ни с каким другим файлом. Заголовочные файлы, которые должны содержать только объявления и без определений, как правило, не получают свой собственный соответствующий файл .o.
После того, как все ваши файлы кода были превращены в объекты кода, компилятор соединит их все вместе и вызовет компоновщик. Компоновщик разрешит все внешние ссылки, а затем создаст исполняемый файл.
Дело в том, что заголовочные файлы сообщают компилятору, что функция или метод где-то существует . Этого достаточно на текущем этапе компиляции для создания объектных файлов: компилятору просто нужно сообщить, что существует, а не где находится определение. Это нужно знать только в том случае, если вы действительно ссылаетесь.
Поскольку все ваши объектные файлы кода упакованы вместе, вся ваша программа получает доступ ко всему, что было публично объявлено внутри себя. Вот почему вам не нужно явно «связывать» CarAPP.m с CarClass.m.
Также возможно ввести в заблуждение компилятор и объявить функции в заголовочных файлах, которые нигде не определены. Если вы используете их в своей программе, первые этапы компиляции пройдут нормально (без синтаксической ошибки, без «необъявленной функции»), но они прервутся во время компоновки, поскольку компоновщик не сможет найти несуществующую функцию .