Повторно используемые классы Obj-C с пользовательскими значениями: правильный путь - PullRequest
Новая
       24

Повторно используемые классы Obj-C с пользовательскими значениями: правильный путь

4 голосов
/ 16 апреля 2010

Я пытаюсь повторно использовать группу предложений Obj-C между приложениями iPhone. Значения, которые различаются в разных приложениях, были изолированы, и я пытаюсь найти наилучший способ применить эти пользовательские значения к классам в зависимости от приложения.

Должен ли я держать их в коде? 

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

Должен ли я хранить их в большом 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];

Должен ли я иметь немного, необязательно n_settings.plist с для каждого класса? 

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

Или есть ОО-решение, о котором я вообще не думаю, что было бы лучше?

Ответы [ 3 ]

1 голос
/ 16 апреля 2010

Я бы дал делегат каждому члену класса, чтобы спросить, какими должны быть мелкие детали. Какой шрифт я должен использовать? Я пойду спросить моего делегата. Это не обязательно должен быть один и тот же делегат для каждого класса или экземпляра, но это может быть. Для значений, которые могут иметь значения по умолчанию, используйте respondsToSelector:, чтобы разрешить дополнительные методы делегата.

Вы можете заставить делегата просмотреть подробности в файле xml / plist, и в этом случае у вас все это будет в одном месте, и вы даже можете загрузить новый файл, чтобы изменить мелкие детали.

Все ваши классы могут иметь один и тот же метод initWithDelegate:, который упрощает создание экземпляра, не зная, что это такое.

1 голос
/ 17 апреля 2010

Prariedogg,

Абсолютно экстернализуйте настройки в нечто, похожее на plist. Вы даже можете иметь несколько списков, которые соответствуют конкретной ситуации (например, settingsMac.plist, settingsIPhone.plist).

Когда ваше приложение определяет, в какой среде оно работает, оно загружает соответствующие параметры через делегата или центральный синглтон.

За счет его извлечения вы уменьшите среднюю стоимость обслуживания приложения. Управление и развертывание обновлений plist дешевле, чем перекомпиляция / повторная проверка / повторная упаковка / повторное развертывание.

- Фрэнк

1 голос
/ 16 апреля 2010

Я бы лично рассмотрел какой-то класс «настроек» в традиции источников данных Objective-C. Установите класс, который отвечает за то, чтобы быть «источником данных» для каждого отдельного приложения: пусть он предоставляет либо набор методов для значений, которые вам нужны для этого конкретного приложения, либо единственный метод «getValueForKey», который возвращает соответствующее значение .

В любом случае, решение:

  • Сохраняет значения в коде
  • Удаляет накладные расходы одного массивного списка для каждого параметра, некоторые из которых могут не использоваться
  • Удаляет работу по разбивке пучков крошечных файлов plist
  • Позволяет другим классам вызывать ваш источник данных везде, где им это нужно
  • Предоставляет вам гибкость OO (теоретически вы можете создать подкласс для своего источника данных в случае возникновения ситуации или необходимости)
  • Локализует изменения, которые необходимо внести; просто включите класс источника данных как часть набора классов, которые вы повторно используете из приложения в приложение, и настройте только этот класс соответствующим образом (вместо того, чтобы изменять что-либо в других классах)
  • Позволяет установить разумные значения по умолчанию - или даже выбросить исключения - для значений данных, которые, как вы ожидаете, не потребуются в конкретном приложении, без необходимости явного запасного кода в каждом вызывающем классе (запишите значение по умолчанию или исключение один раз в класс источника данных)
...