Was ist der Grund dafür, #import-Anweisungen in .m-Dateien anstelle von .h-Dateien in Objective-C zu platzieren?
Apple-Beispiele bündeln diese in der .m-Datei, sofern das Objekt nicht in der Schnittstellendeklaration (.h) verwendet wird, und die Dokumentation gibt an, dass dies korrekt ist ("In der Schnittstellendatei importieren Sie zuerst alle erforderlichen Headerdateien.")
Was mich verwirrt, ist, dass .h die Schnittstelle für die Implementierung definieren soll, also würde #import logischerweise auf die .h-Datei statt auf .m gehen.
In jeder Quelldatei sollten Sie nur # importieren, was Sie brauchen, um diese Datei für die Kompilierung gültig zu machen. Denken Sie daran, dass Ihre Header möglicherweise von anderen Klassen verwendet werden, daher sollten Sie sie so leicht wie möglich gestalten. Aus diesem Grund ist es auch besser, @class für Vorwärtsdeklarationen anderer Klassen als Ihre Oberklasse zu verwenden.
Wenn Sie all Ihre #import s in die Header-Dateien einfügen, können keine zwei Klassen voneinander abhängig sein, da eine Datei keine Datei importieren kann, die sie importiert. Wenn Sie stattdessen #import in die Implementierungsdatei einfügen, verschwindet das Problem.
Wenn die Schnittstelle Ihrer Klasse von der Schnittstelle einer anderen Klasse abhängt (dh wenn es sich um eine Unterklasse handelt), fügen Sie den Header hinzu, andernfalls deklarieren Sie die andere Klasse mit @class und fügen Sie den Interface-Header dieser Klasse in die Quelle der abhängigen Klasse ein Datei.
Die Argumentation ist einfach; Indem Sie nur Klassen im Header referenzieren, anstatt die gesamte Schnittstelle zu importieren, können Sie gegenseitig abhängige Klassen definieren (dh Klassen, die voneinander abhängig sind), andernfalls ist eine solche Einrichtung unmöglich, da rekursive Dateieinschlüsse auftreten würden (aber die Objective-C #import stellt sicher, dass das nicht passiert).
Eine Schnittstelle ist typischerweise nur die Methoden, die die Klasse zur Verfügung stellt. Eine Schnittstelle kann eine beliebige Anzahl von austauschbaren Implementierungen haben. Der Import in die Implementierung statt in den Header verhindert, dass andere Implementierungen Klassen importieren, die möglicherweise nicht verwendet werden müssen. Es geht darum, Informationen zu verstecken und Code auf einer Basis zu halten, die man wissen muss.
Was ist der Grund dafür, #import-Anweisungen in .m-Dateien anstelle von .h-Dateien in Objective-C zu platzieren?
Vielleicht haben Sie in einer der Methoden in der Implementierung eine lokale Variable eines Klassentyps instanziiert, die Sie nur ein- oder zweimal verwenden, und Sie möchten nicht, dass die #import -Anweisung Ihre Header-Datei durcheinanderbringt. Oder Sie haben @class in der Kopfzeile als Forward-Deklaration verwendet und müssen diese Klasse in Ihrer Implementierung mit der #import -Anweisung referenzieren.
Abgesehen von allem anderen ist es auch ein Leistungsgewinn für die Kompilierzeiten. Wenn Sie #import eine Datei verwenden, ist es so, als hätten Sie den Inhalt der Datei in Ihre Kopfzeile eingefügt. Das ist mehr, als dass der Compiler beim Kompilieren des Codes durchkommt.
Sehen Sie sich die Seite zur Clang-Compiler-Leistung an .
Beachten Sie, dass vorkompilierte Header einen Großteil des Problems bei Standardheadern wie Cocoa.h vermeiden.
Tags und Links objective-c