Quelle est la justification de la mise en place #Import des déclarations dans .m plutôt que des fichiers dans l'objectif-c?
Les exemples Apple les regroupent dans le fichier .m à moins que l'objet n'est utilisé dans la déclaration d'interface (.h) et les documents indiquent que cela est correct ("dans le fichier d'interface, vous importerez d'abord les fichiers d'en-tête requis.")
Qu'est-ce qui me confondre est que .h est censé définir l'interface pour la mise en œuvre, de sorte que #import allez logiquement à .h fichier au lieu de .m.
6 Réponses :
Quelle est la justification de la mise en place #Import des déclarations dans .m plutôt que des fichiers dans l'objectif-c?
Peut-être dans l'une des méthodes de la mise en œuvre, vous avez instancié une variable locale d'un type de classe que vous ne pouvez utiliser qu'une seule ou deux fois, et vous ne souhaitez pas avoir la déclaration
#import encombrer votre fichier d'en-tête. Ou vous avez peut-être utilisé@class dans l'en-tête sous forme de déclaration à terme, et vous devez faire référence à cette classe dans votre implémentation avec l'instruction#import .
Si vous mettez tous votre #import S dans les fichiers d'en-tête, aucune deux classes ne peut dépendre mutuellement l'un de l'autre, car un fichier ne peut importer de fichier qui l'importe. Si vous mettez le #import dans le fichier de mise en œuvre, d'autre part, le problème disparaît.
Une interface est typiquement des méthodes que la classe est disponible. Une interface peut avoir un nombre quelconque d'implémentations interchangeables. L'importation à l'intérieur de la mise en œuvre plutôt que de l'intérieur L'en-tête empêche d'autres implémentations des classes d'importation, il peut ne pas nécessiter d'utiliser. Il s'agit de cacher des informations et de garder le code sur une base de base.
Dans n'importe quel fichier source, vous devez seulement #Importer ce que vous devez apporter ce fichier valide pour la compilation. N'oubliez pas que vos en-têtes pourraient être utilisés par d'autres classes, vous souhaitez donc les rendre aussi légers que possible. C'est aussi pourquoi il est préférable d'utiliser @class pour des déclarations de classes à terme autres que votre superclasse.
Si l'interface de votre classe dépend de l'interface d'une autre classe (c'est-à-dire s'il s'agit d'une sous-classe), incluez l'en-tête, sinon redéprégnez-le à la suite de l'autre classe avec Le raisonnement est simple; En référençant uniquement des classes dans l'en-tête plutôt que d'importer toute l'interface, vous pouvez définir des classes mutuellement dépendantes (c.-à-d. CLASSES qui dépendent de l'autre), sinon une telle configuration est impossible car l'inclusion de fichiers récursif se produirait (mais l'objectif-c @class et incluez cette classe En-tête d'interface dans le fichier source de la classe dépendante.
#import s'assure que cela ne se produit pas).
Tout ce qui est de côté, c'est aussi une victoire de performance pour la compilation. Lorsque vous Voir ce page de la performance de CLANG COMPILER .
Notez que les en-têtes précompilés atténuent une grande partie du problème dans le cas des en-têtes standard tels que Cocoa.h. #import un fichier, c'est comme si vous avez collé le contenu du fichier dans votre en-tête. C'est plus de choses pour le compilateur pour obtenir lors de la compilation de votre code.
Merci pour des réponses, tous ont des points valides pour tout +1 à tous et marqué la plupart des "éclairants" comme réponse.
Grande question! Les réponses à cette question m'a beaucoup aidé avec un problème de dépendance circulaire que j'avais.