Utilisation de extern dans l’objective C

Dans quelle mesure est-il utile d’utiliser extern dans l’objective C? Cela facilite le codage de certaines parties. Mais cela ne gâche-t-il pas l’orientation de l’object?

Vous constaterez que extern est largement utilisé dans les frameworks Cocoa, et il serait difficile de trouver un argument convaincant que leur OO est “gâté”. Au contraire, Cocoa est bien encapsulé et n’expose que ce qu’il doit, souvent via extern. Les constantes définies globalement sont certainement l’utilisation la plus courante, mais pas nécessairement la seule utilisation valide.

IMO, utiliser extern ne gâche pas nécessairement l’orientation de l’object. Même dans OO, il est fréquent d’utiliser des variables accessibles de n’importe où. L’utilisation de extern est la solution de contournement la plus fréquente pour l’absence de “variables de classe” (comme celles déclarées avec static en Java) dans Objective-C. Il vous permet d’étendre le champ d’application dans lequel vous pouvez référencer un symbole au-delà de l’unité de compilation où il est déclaré, en promettant essentiellement qu’il sera défini quelque part par quelqu’un.

Vous pouvez également combiner extern avec __atsortingbute__((visibility("hidden"))) pour créer un symbole pouvant être utilisé en dehors de son unité de compilation, mais pas en dehors de son unité de liaison, pour ainsi dire. Je l’ai utilisé pour la bibliothèque personnalisée et le code d’infrastructure pour encapsuler correctement les détails internes de niveau supérieur.

Il existe des cas d’utilisation pour le mot clé extern dans Objective-C.
Aaron Hillegass suggère de créer des noms de notification mondiaux externes. par exemple:

 extern NSSsortingng* const XYYourNotification; 

Vous définissez ensuite le NSSsortingng* réel dans votre implémentation

Cela dépend de quoi vous l’utilisez. Il est parfaitement valable de l’utiliser pour accéder à des constantes définies globalement.
Si vous avez un object global, je vous suggérerais plutôt d’utiliser Singleton .

Cela dépend de vos besoins, par exemple vous avez une page de connexion. Une fois connecté, vous notifiez les autres pages des applications.

 #import  extern NSSsortingng *const DidLoginNotification; @interface LoginViewController : NSObject - (void)login; @end // LoginViewController.m #import "LoginViewController.h" //define extern const in implementation file only once for the whole process NSSsortingng *const DidLoginNotification =    @"DidLoginNotificationNotified"; @implementation LoginViewController - (void)login {    // Perform notification [[NSNotificationCenter defaultCenter]; sendNotificationName: DidLoginNotification                    object:nil]; } 

Le destinataire de la notification n’a pas besoin de connaître la valeur du const.

Un autre exemple de problème lorsque vous n’utilisez pas extern :

Disons que vous avez une variable globale dans un fichier d’en-tête:

 NSSsortingng *globalVar = @"Wonderful"; 

Et vous l’utilisez à 3 endroits en important ce fichier d’en-tête. Votre code ne sera pas compilé, l’éditeur de liens se plaint d’avoir 3 symboles en double définis dans votre code. Pour le résoudre, vous avez deux possibilités:

Utilisez static , auquel cas chaque fichier qui importe cet en-tête aura sa propre référence définie (et le changement d’une chaîne n’affectera pas les autres chaînes imscopes dans d’autres fichiers):

 static NSSsortingng *globalVar = @"Wonderful"; 

Utilisez extern dans le fichier .h et définissez-le dans le fichier .m. De cette façon, une seule référence sera définie et chaque fichier utilisera la même référence (les modifications étant reflétées dans tous les fichiers):

 extern NSSsortingng *globalVar; // in .h NSSsortingng *globalVar = @"Wonderful"; // in .m 

Choisissez celui qui convient le mieux.