Wiederverwendbare Obj-C-Klassen mit benutzerdefinierten Werten: Der richtige Weg

Question

Ich versuche, eine Gruppe von Obj-C Clases zwischen iPhone-Anwendungen wiederzuverwenden. Die Werte, die sich von App zu App unterscheiden, wurden isoliert und ich versuche herauszufinden, wie ich diese benutzerdefinierten Werte am besten auf die Klassen auf einer App-zu-App-Basis anwenden kann.

Sollte ich sie in einem Code festhalten?

// 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];

Soll ich sie in einem großen Behälter aufbewahren? 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];

Sollte ich kleine, optionale n_settings.plist s für jede Klasse?

// 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];

Oder gibt es eine OO-Lösung, an die ich noch gar nicht gedacht habe, die besser wäre?

Answer 1

Ich persönlich würde eine Art "Einstellungen"-Klasse in Betracht ziehen, in der Tradition der Objective-C-Datenquellen. Richten Sie eine Klasse ein, die dafür verantwortlich ist, eine "Datenquelle" für jede einzelne App zu sein: Stellen Sie entweder eine Reihe von Methoden für die Werte bereit, die Sie für diese spezielle App benötigen, oder eine einzelne Methode im Stil von "getValueForKey", die den entsprechenden Wert zurückgibt.

So oder so, die Lösung:

• Behält Werte im Code bei
• Beseitigt den Overhead einer riesigen Liste für jede Einstellung, von der einige möglicherweise nicht verwendet werden
• Entfernt die Arbeit des Aufteilens von Haufen kleiner plist-Dateien
• Ermöglicht es Ihnen, andere Klassen Ihre Datenquelle aufrufen zu lassen, wo immer sie sie benötigen
• Bietet Ihnen die Flexibilität von OO (Sie könnten Ihre Datenquelle theoretisch in Unterklassen einteilen, falls die Situation oder der Bedarf entsteht)
• Lokalisieren Sie die Änderungen, die Sie vornehmen müssen; fügen Sie einfach die Datenquellenklasse als Teil des Klassensatzes ein, den Sie von Anwendung zu Anwendung wiederverwenden, und passen Sie nur diese Klasse entsprechend an (anstatt Dinge in anderen Klassen ändern zu müssen)
• Ermöglicht es Ihnen, vernünftige Standardwerte - oder sogar Ausnahmen - für Datenwerte festzulegen, von denen Sie nicht erwarten, dass sie in einer bestimmten Anwendung benötigt werden, ohne dass expliziter Fallback-Code in jeder aufrufenden Klasse erforderlich ist (schreiben Sie den Standardwert oder die Ausnahme einmal in die Datenquellenklasse)

Answer 2

Ich würde jeder Klasse ein delegiertes Mitglied zur Seite stellen, um zu fragen, wie die Feinheiten aussehen sollen. Welche Schriftart soll ich verwenden? Ich werde meinen Delegierten fragen. Es muss nicht für jede Klasse oder Instanz derselbe Delegierte sein, aber es kann sein. Für Werte, die Voreinstellungen haben können, verwenden Sie respondsToSelector: um optionale Delegatmethoden zu ermöglichen.

Sie könnten den Delegierten veranlassen, in einer Xml/Plist-Datei nach den Details zu suchen. In diesem Fall haben Sie alles an einem Ort und können sogar eine neue Datei herunterladen, um kleine Details zu ändern.

Alle Ihre Klassen können die gleiche initWithDelegate: Methode, was es einfacher macht, eine zu instanziieren, ohne zu wissen, was sie ist.

Answer 3

Prariedogg,

Die Einstellungen sollten auf jeden Fall in eine plist ausgelagert werden. Sie können sogar mehrere Plists haben, die auf die jeweilige Situation abgestimmt sind (z. B. settingsMac.plist, settingsIPhone.plist).

Wenn Ihre Anwendung feststellt, in welcher Umgebung sie ausgeführt wird, lädt sie die entsprechenden Einstellungen über einen Delegaten oder ein zentrales Singleton.

Durch die Auslagerung werden die durchschnittlichen Wartungskosten der Anwendung gesenkt. Die Kosten für die Verwaltung und Bereitstellung von Plist-Updates sind geringer als die Kosten für Neukompilierung, Neupaketierung und Neubereitstellung.

-- Frank