Étendre NSMutableArray pour la gestion d'association bidirectionnelle

Question

Je suis un grand fan de la génération de code (à partir d'UML) et venant du monde Java, je me demande comment j'implémenterais la gestion d'association bidirectionnelle automatisée dans Objective-C.

Image d'une association Partenaire < -> Adresse, un-à-plusieurs et navigable à partir des deux extrémités. Ce que je voudrais réaliser, c'est que si j'ajoute une Adresse à un Partenaire, cet objet Adresse devrait automatiquement connaître son Partenaire. Par conséquent, le modèle d'implémentation doit comporter un NSMutableArray * du côté du partenaire et un partenaire * du côté de l'adresse. La propriété du côté Adresse est facile à implémenter car setPartner: (Partner *) aPartner peut automatiquement insérer l'adresse (self) dans le NSMutableArray du partenaire gérant les adresses. L'autre côté, cependant, n'est pas si facile à mettre en œuvre. Le modèle d'implémentation standard pour les références trop nombreuses dans Objective-C semble être NSMutableArray, obtenu via la méthode get de @property. L'objet en possession de ce NSMutableArray pourrait alors insérer un objet Address dans le tableau, ce qui ne serait bien sûr pas mettre à jour l'autre côté.

Je sais qu'il existe d'autres modèles pour ce type de gestion d'association, par exemple, via les méthodes addTo ...() et removeFrom ...(). Mais je ne sais pas encore si cela correspondrait à d'autres principes de la programmation Cocoa ou même m'empêcherait d'utiliser Cocoa efficacement. Je pense à Interface Builder ici. Pas beaucoup d'expérience, mais j'ai vu quelque chose appelé un ArrayController qui semble être très pratique mais qui semble aussi s'attendre à une propriété de type NSMutableArray avec laquelle travailler. Et si ce type insère des objets dans le tableau, j'ai besoin d'intercepter cela et de faire l'ajustement de l'autre côté.

En tant que programmeur Java, j'aurais tendance à sous-classer NSMutableArray maintenant et remplacer certaines de ses méthodes qui pourraient alors manipuler l'autre extrémité. Serait-ce possible? J'ai lu sur les catégories, mais jusqu'à présent, j'ai compris que je pouvais seulement ajouter des méthodes à une classe de cette façon et ne pas les ignorer ni ajouter à la structure de celui-ci. Ou devrait-il être le transfert de méthode? Je suis confus en ce moment. Si vous pouviez me diriger dans la bonne direction en pensant que ce serait génial. Merci beaucoup!

Answer 1

Bienvenue sur Cocoa. Ne sous-classez pas les collections intégrées. Vous allez devenir fou. Permettez-moi de clarifier: dans Cocoa, nous avons ces choses appelées "Class Clusters". Les clusters sont une hiérarchie de classes privées qui ont toutes une superclasse publique commune. Dans ce cas, NSArray est la superclasse publique, et il existe des sous-classes privées qui sont les implémentations de tableau réelles. Cela présente un défi très difficile lors du sous-classement, car vous ne savez pas quelle classe (ou classes) vous auriez besoin de sous-classer.

Le travail autour est commun pour créer une nouvelle NSObject sous-classe « wraps » un NSArray (elle a le tableau comme une variable d'instance [ « champ »]), puis vous appeler des méthodes sur l'emballage personnalisé, et le wrapper contient toute la logique personnalisée dont vous avez besoin. Pour répondre à votre question, j'ai découvert que lorsque j'ai ce genre de configuration où je dois gérer automatiquement des relations un-à-un, un-à-plusieurs ou plusieurs-à-plusieurs, il y a rien qui bat en utilisant CoreData. CoreData est un framework intégré qui ressemble plus ou moins à un magasin d'objets. L'une des choses vraiment géniales est de gérer l'intégrité des relations, ce que vous recherchez.