Différence entre les méthodes déclarantes dans le fichier .h et dans le fichier .m spécifiant @interface et @end

Question

Je ne comprends tout simplement pas pourquoi certains types déclarent les méthodes dans le fichier .m. Ces déclarations ne peuvent-elles pas aller dans le fichier .h? Voici ce que je vois la plupart du temps:

//myClass.h 

#import <UIKit/UIKit.h> 

@interface myClass: UIViewController 
{ 

} 

@end 

et la mise en œuvre (.m) partie:

//myClass.m 

#import "myClass.h" 

@interface myClass 

//declare some methods here 

@end 

@implementation myClass 

//the actual implementation 

@end 

est-il une différence lorsque les méthodes sont déclarées de cette façon ?? De plus, les méthodes "@private" peuvent être déclarées dans myClass.h lui-même, n'est-ce pas?

Answer 1

Le code que vous avez publié à la fois ne compile pas et n'équivaut pas à déclarer des méthodes dans l'en-tête.

Le but de l'en-tête est de fournir un ensemble de déclarations que d'autres classes peuvent importer. Ils ne peuvent pas importer votre fichier d'implémentation, car cela créera des définitions en double. Comme l'a dit bbum, ce que vous voyez probablement est déclarations de méthodes privées dans le fichier d'implémentation. Ils ne sont pas destinés à être utilisés en dehors de la classe, ils sont donc déclarés dans le fichier d'implémentation. La fonction est appelée une extension de classe:

//MyClass.h 

#import <UIKit/UIKit.h> 

@interface MyClass: UIViewController 

// Declare methods that other classes should call here 

@end 

//MyClass.m 

#import "MyClass.h" 

@interface MyClass() // <--- NOTE THE PARENTHESES HERE 

// Declare methods that only this class should be using here 

@end 

@implementation MyClass 

// Define all your methods here 

@end 

Et non, vous ne pouvez pas déclarer « @private méthodes » dans l'en-tête, ou nulle part ailleurs. Il n'y a pas de telle chose dans Objective-C. Le spécificateur d'accès @private ne s'applique qu'aux variables.

Answer 2

• MyClass, et non myClass; les cours commencent par des majuscules.

Je serais surpris si ce code compile du tout. Si dans le .m, vous deviez dire:

@interface MyClass() 
@end 

Ensuite, ce serait une extension de classe, qui a été discuté à plusieurs reprises sur le SO. En l'état, vous déclarez un @interface conflictuel pour MyClass et le compilateur doit se plaindre.

Answer 3

Il s'agit de garder la séparation entre les interfaces publiques et privées à votre classe. Etre capable de déclarer des méthodes, des propriétés et des iVars dans le fichier d'implémentation est un indicateur clair de ce que vous pouvez faire et utiliser dans la classe et de ce qui peut être fait depuis l'extérieur de la classe.

Vous pouvez également redéfinir les propriétés. Par exemple:

dans .h

@property (readonly, copy) NSString *aString; 

dans .m

@property (readwrite, copy) NSString *aString; 

donc à partir de votre classe, vous pouvez traiter la propriété comme readwrite, mais à l'extérieur, la propriété est lecture seulement.

Answer 4

J'ai plusieurs fois déclaré des classes internes (différemment nommées de la classe principale) dans le fichier .m.Ce sont des classes utilisées par la classe principale que le .m contient (et qui a été déclaré dans le .h). De cette façon, la classe interne est "privée", plus, avec tout dans un fichier, il est plus facile à lire et à mettre à jour tout en travaillant sur l'implémentation de la classe principale.