Это именно так:
#import <SomeFramework/SomeFramework.h>
работает.
Это приведет к дополнительным расходам - возможно, будет прочитано больше файлов, а затем проанализировано больше. Это приемлемое количество накладных расходов - решать вам.
Программы ObjC могут быть разработаны так, чтобы иметь очень очень небольшую физическую зависимость, и с #import
вы экономите тонну избыточного повторного открытия заголовков (против заголовков, которые могут быть включены несколько раз). Следовательно, воздействие будет довольно небольшим, если все сделано правильно.
Более серьезная проблема может заключаться в том, чтобы выяснить, как избежать выставления другим фреймворкам вашего клиента.
#import <SomeFramework0/SomeFramework0.h>
#import <SomeFramework1/SomeFramework1.h>
#import <SomeFramework2/SomeFramework2.h>
#import <SomeFramework3/SomeFramework3.h>
#import <SomeFramework4/SomeFramework4.h>
#import <SomeFramework5/SomeFramework5.h>
200 строк из ваших заголовков против 200 заголовков из зависимостей библиотеки ...
Я часто делаю то, что вы предлагаете, чтобы оградить клиентов от изменений в зависимостях. Они не хотят #include
каждый класс в отдельности и утверждают, что по мере того, как все меняется, они просто хотят использовать библиотеку / пакет без хлопот.