Objectif C, classes et variables globales

Question

J'ai appris Objective-C et j'ai récemment commencé à utiliser des classes (au lieu de tout avoir dans ViewController). Je rencontre un problème en ce que je ne sais pas quoi faire avec les variables que je veux être accessible dans d'autres classes.

J'ai un NSArray de UIView qui est créé dans mon "ViewController". Il est ensuite transmis à mon "LayoutManager" qui définit leur cadre en fonction de la taille de l'écran. Ce tableau doit également être accessible à partir de mes "BlockManager" et "ColorManager".

Quelle est la meilleure façon de gérer ce tableau et d'autres variables dans des cas similaires. Devrais-je utiliser une variable globale, et si oui, comment? Ou y a-t-il une meilleure façon de le faire?

Answer 1

Les variables globales sont généralement une mauvaise idée dans la programmation orientée objet (le modèle singleton étant peut-être une exception acceptable, bien que les opinions varient). En général, vous voulez aussi éviter de partager des données brutes et laisser tout le monde faire tout ce qu'il veut - vous finissez par avoir besoin de donner à tout le monde la connaissance interne de l'implémentation de tout le monde et cela devient extrêmement difficile à gérer.

Dans votre cas, il semble que LayoutManager est une tâche ponctuelle (ou peut-être une fois par rotation?), Donc il serait bien de dire que l'interaction de l'objet est «voici mes vues, s'il vous plaît les dimensionner» et de faire que tout le cycle de vie de l'objet. Donc, vous passeriez le tableau à init, vous laisserais la classe s'exécuter une fois que vous le lâcheriez.

Si BlockManager et ColorManager ont quelque chose dont ils ont besoin de communiquer à votre contrôleur de vue concernant ses vues, vous devriez probablement créer des protocoles délégués appropriés. Ensuite, la ligne de communication est qu'ils permettent au contrôleur de vue de savoir tout ce qu'ils ont calculé, il doit savoir et il est responsable de prendre des mesures sur le tableau.

Answer 2

Il semble que vous rencontriez peut-être le problème de l'utilisation abusive de Singletons pour gérer des contrôleurs qui n'ont pas besoin d'être des Singletons. Cela peut être utile:

• What is so bad about singletons?
• Are Singletons really that bad?
• Alternative to Singleton in Objective-C for better application design

J'ai récemment retravaillé mon programme entier de singleton à des objets passant le long comme ils sont nécessaires. Notez que les objets globaux singleton et partagés ne sont pas identiques et que les propres classes d'Apple utilisent sharedObject ou defaultObject qui instancie et renvoie une instance partagée, mais rien ne vous empêche de créer réellement une autre instance de la classe pour vos propres besoins. D'autre part, Singleton limite l'objet à une seule instance, ce qui signifie qu'il ne doit plus avoir deux instances (ce qui pourrait être nécessaire dans le futur) pour bénéficier d'un accès complet depuis n'importe où. En ce sens, vous n'avez vraiment besoin que de la partie accès total et non de la restriction d'une instance unique, donc vous pourriez considérer le modèle sharedObject. Voici un exemple:

// Up the top in the .m file 
static MySharedClass *sharedInstance; 

// A class method to return the shared instance 
+ (MySharedClass *)sharedInstance { 
    if (!sharedInstance) { 
     sharedInstance = [[MySharedClass alloc] init]; 
    } 
    return sharedInstance; 
} 

Cela dit, je considérerais la structuration de votre programme pour passer des objets car ils sont nécessaires plutôt que de mettre en place tout le monde pour l'accès par tout. Sinon, le code que vous écrivez avec une utilisation excessive des objets singleton/global est beaucoup plus couplé et ne peut pas être retiré du projet courant et utilisé ailleurs, et rend le débogage plus difficile car vous devez considérer l'état global de ces classes de gestionnaire.

Je voudrais créer mon contrôleur principal (ViewController) qui instanciera alors les autres classes de contrôleur nécessaires et passera les ressources entre eux. Ce NSArray de UIViews que vous mentionnez serait stocké aussi haut dans la chaîne que nécessaire, vraisemblablement tout en haut. Ce Présentateur créerait alors le LayoutManager et lui passerait les objets nécessaires pour un travail ultérieur. Et de la même manière, je passerais ces objets à BlockManager et ColorManager.