Qu'est-ce qui ne va pas avec extern NSMutableArray?

Question

J'ai donc beaucoup lu. Et j'ai pu enfin déclarer un MutableArray externe et y accéder à partir de différentes vues. J'ai deux vues: 1) Test View Controller 2) Test2

Je déclare le tableau comme suit: TestingViewController.h

extern NSMutableArray *myArray; 

#import <UIKit/UIKit.h> 

@interface TestingViewController : UIViewController { 

} 

j'initialiser le tableau lorsque les charges de TestingViewController. Ensuite, je peux ajouter des objets de test 2 comme suit: Test2.m

#import "Test2.h" 

NSMutableArray *myArray; 
@implementation Test2 

-(IBAction)addToArray{ 
[myArray addObject:@"Hot like Mexico"]; 
NSLog(@"Object was added to Array! Count: %d",[myArray count]); 
} 

Il semble fonctionner à partir des deux vues. Le nombre et les objets sont consistants même lors de la commutation.

Ce que je veux savoir est, quel est le problème avec ceci? Je sais que beaucoup de programmeurs expérimentés détestent les variables globales, mais la seule façon de les faire fonctionner est comme ci-dessus et à travers l'AppDelegate (Ne pas vouloir le faire comme ça). Simplement essayer d'être plus efficace avec l'ajout et la manipulation de tableaux à partir de plusieurs vues.

Merci les gars!

Answer 1

Si vous avez vraiment besoin d'un objet "global", voici un motif simple que j'utilise beaucoup - enfin, pas beaucoup, car je n'ai pas tendance à avoir beaucoup de globals.

Choisissez la classe à laquelle vous voulez appartenir. Supposons que Test2 soit la classe logique à utiliser. Créez une méthode dans Test2 pour accéder à la variable.(Pourrait être une méthode de classe ou une méthode d'instance) comme suit:

@interface Test2 : NSObject 
{ 
    // ivars 
} 

+(NSMutableArray*) myArray; // could also be an instance method 

@end 

@implementation Test2 

+(NSMutableArray*) myArray 
{ 
    static NSMutableArray* theValue = nil; 
    @synchronized([Test2 class]) // in a single threaded app you can omit the sync block 
    { 
     if (theValue == nil) 
     { 
      theValue = [[NSMutableArray alloc] init]; 
     } 
    } 
    return theValue; 
} 
@end 

Edit: En utilisant la méthode de classe, pour accéder monTableau de partout faire ceci:

#import "Test2.h" 

// To use class method, send messages to the class itself 

[[Test2 myArray] addObject: @"foo bar"]; 
id foo = [[Test2 myArray] objectAtIndex: 0]; 

Answer 2

Le problème avec les variables globales est qu'elles prolifèrent. D'abord vous en avez un, puis vous en avez besoin, et avant que vous le sachiez, vous avez des dizaines de variables globales, vous ne savez pas où les variables sont initialisées et libérées, et chaque changement prend une éternité, parce que vous ne savez pas quelles sont les dépendances entre les composants.

Généralement, vous devez avoir un propriétaire identifié pour chaque ressource du programme. Dans une application Cocoa, les divers objets contrôleur et délégué fournissent une hiérarchie naturelle de responsabilité pour les différentes parties de la conception.

---

Pour le cas particulier où vous avez un objet dont vous avez besoin pour être accessible à plusieurs vues de votre application, vous devriez généralement faire l'objet disponible par une méthode de votre point de vue classe contrôleur, puis assurez-vous que chaque La vue a une référence au contrôleur.

Pour un exemple, consultez l'un des exemples de UITableView. Il y a un protocole de source de données assez compliqué utilisé ici, mais d'autres classes UIKit ont une propriété "delegate" qui est généralement initialisée à un objet qui gère une partie de leur état pour eux.

Answer 3

Les variables globales sont des cauchemars quand il s'agit de gestion de la mémoire, et ce n'est vraiment pas la manière typique de faire les choses en termes de conception. La façon correcte de le faire serait de déclarer myArray comme une propriété dans TestingViewController, puis d'accéder à cette propriété à partir de Test2.

Answer 4

On dirait que vous avez besoin d'un singleton . http://cocoawithlove.com/2008/11/singletons-appdelegates-and-top-level.html