Classes Obj-C réutilisables avec des valeurs personnalisées: la bonne façon

Question

J'essaie de réutiliser un groupe de clases Obj-C entre des applications iPhone. Les valeurs qui diffèrent d'une application à l'autre ont été isolées et j'essaie de déterminer la meilleure façon d'appliquer ces valeurs personnalisées aux classes, d'une application à l'autre.

Devrais-je les tenir dans le code?

// I might have 10 customizable values for each class, that's a long signature! 
CarController *controller = [[CarController alloc] initWithFontName:@"Vroom" engine:@"Diesel" color:@"Red" number:11]; 

Devrais-je les stocker dans un grand settings.plist?

// Wasteful! I sometimes only use 2-3 of 50 settings! 
AllMyAppSettings *settings = [[AllMyAppSettings alloc] initFromDisk:@"settings.plist"]; 
CarController *controller = [[CarController alloc] initWithSettings:settings]; 
[settings release]; 

Dois-je avoir peu, en option n_settings.plist s pour chaque classe?

// Sometimes I customize 
CarControllerSettings *carSettings = [[CarControllerSettings alloc] initFromDisk:@"car_settings.plist"]; 
CarController *controller = [[CarController alloc] initWithSettings:carSettings]; 
[carSettings release]; 

// Sometimes I don't, and CarController falls back to internally stored, reasonable defaults. 
CarController *controller = [[CarController alloc] initWithSettings:nil]; 

Ou y at-il une solution OO à laquelle je ne pense pas du tout qui serait mieux?

Answer 1

Je considérerais personnellement une sorte de classe "settings", dans la tradition des sources de données Objective-C. Configurez une classe responsable d'être une "source de données" pour chaque application: fournissez-lui un ensemble de méthodes pour les valeurs dont vous avez besoin pour cette application particulière, ou une seule méthode "getValueForKey" qui renvoie la valeur appropriée .

De toute façon, la solution:

• Maintient les valeurs dans le code
• Supprime les frais généraux d'un plist massif pour tous les milieux, dont certains ne peuvent être utilisés
• Enlève le travail de séparation des paquets de minuscules fichiers plist
• Vous permet d'avoir d'autres classes appellent votre source de données partout où ils en ont besoin
• Vous donne la flexibilité de OO (vous pourriez, en théorie, sous-classer vos données aig si la situation ou le besoin survient)
• Localise les modifications à apporter; Il suffit d'inclure la classe de source de données dans l'ensemble des classes que vous réutilisez d'une application à l'autre et de modifier cette classe selon vos besoins (plutôt que d'avoir à changer les choses dans d'autres classes)
• Permet de définir des valeurs par défaut raisonnables même lancer des exceptions - pour les valeurs de données que vous ne souhaitez pas avoir dans une application particulière, sans avoir besoin d'un code de secours explicite dans chaque classe appelante (écrire une exception ou une exception dans la classe source de données)

Answer 2

Je donnerais un membre délégué à chaque classe pour demander quels devraient être les détails. Quelle police dois-je utiliser? Je vais demander à mon délégué. Il ne doit pas nécessairement être le même délégué pour chaque classe ou instance, mais cela peut l'être. Pour les valeurs qui peuvent avoir des valeurs par défaut, utilisez respondsToSelector: pour autoriser les méthodes de délégation facultatives. Vous pouvez demander au délégué d'aller chercher dans un fichier xml/plist les détails, auquel cas vous avez tout en un seul endroit et vous pouvez même télécharger un nouveau fichier pour changer les petits détails.

Toutes vos classes peuvent avoir la même méthode initWithDelegate:, ce qui facilite l'instanciation d'une méthode sans savoir de quoi il s'agit.

Answer 3

Prariedogg,

extériorisent Absolument les paramètres dans quelque chose comme un plist.Vous pouvez même avoir plusieurs plists qui correspondent à la situation particulière (par exemple settingsMac.plist, settingsIPhone.plist).

Lorsque votre application détermine l'environnement dans lequel elle s'exécute, elle charge les paramètres appropriés via un délégué ou un singleton central. En l'externalisant, vous réduirez le coût moyen de maintenance de l'application. La gestion et le déploiement des mises à jour de plist sont moins coûteux que recompile/retest/repackage/redeploy.

- Frank