Архитектура iPhone Obj-C в отношении создания экземпляров классов

Question

У меня есть вопрос о том, как создать приложение для iPhone.

У меня есть два основных компонента: карта и аудиоплеер, оба автономных класса (MapController и AudioController). Я прочитал эту замечательную статью и пытаюсь применить ее к своему приложению:

http://blog.shinetech.com/2011/06/14/delegation-notification-and-observation/

У меня есть третий класс, WebServices, который обрабатывает загрузку данных POST на мой сервер, а также делает запросы к внешним API.

Мой вопрос:

1. Импортирую ли я заголовочные файлы и создаю ли новый экземпляр WebServices как в контроллере карты, так и в аудиоплеере? И тогда каждый контроллер может ссылаться на свои собственные веб-сервисы для запросов?
2. Или я должен создать один экземпляр WebServices на RootController, а затем передать его на карту и контроллеры аудио при инициализации?

В частности, меня интересует, какой подход потребляет память более эффективно. Или, если это вообще не имеет значения.

Спасибо!

Answer 1

Рассмотрите возможность создания синглтона для вашего класса WebServices и использования общего экземпляра. Кажется, вам нужен именно этот шаблон дизайна.

Что касается вопроса эффективности, второй вариант более эффективен исключительно потому, что вы не храните столько данных в оперативной памяти. Разница, однако, при условии, что ваши классы не хранят слишком много внутри, вероятно, будет незаметной.

@interface WebServices: NSObject
{
}

+ (WebServices*)sharedInstance;
@end

static WebServices *sharedInstance;
@implementation WebSerivces

+ (WebServices*)sharedInstance
{

  @synchronized(self)
  {
    if (!sharedInstance)
      sharedInstance = [[WebServices alloc] init];

    return sharedInstance;
  }
}

@end

Answer 2

Я бы предложил NSOperationQueue с числом NSOperation с, а не синглтон WebServices.

Посмотрите на этот прекрасный пример от Apple , где они делают это для одновременной загрузки изображений. Это пример Mac, но все показанные классы доступны на iOS. Они используют NSInvocationOperation, но вы можете использовать NSOperation подкласс или NSBlockOperation для более чистого кода.

Вы можете добавить их из любой точки в одну очередь, вызвав [NSOperationQueue mainQueue];, чтобы получить синглтон основной очереди. Работа синглтона, в данном случае, заключается только в управлении очередью (поэтому не происходит слишком много загрузок одновременно), а не в обработке данных (все это обрабатывается вашим NSOperation).

Answer 3

Точка ноль

Не прибегайте к синглетам, и особенно не в многопоточных контекстах. Вы можете искать этот сайт, если вам нужны объяснения (подсказка: причины против них очень похожи в ОО-языках, подобных ObjC. Например, C ++, Java, C # ...).

Поделиться или нет?

Это в конечном итоге зависит от поведения вашего проекта необходимо , но я предпочитаю вариант № 1 по умолчанию.

• Если вам нужно несколько экземпляров, не бойтесь создавать несколько (если у вас нет действительно, действительно, очень веских причин не делать этого).
• Если их сложно построить, подумайте, какими неизменными данными они могут поделиться.
• Пользуйтесь маленькими специализированными предметами (WebServices может быть огромным). Меньшие объекты обеспечивают большую гибкость и снижают вероятность того, что ваша программа будет конкурировать за ресурсы.
• Что вы получите в этом случае, поделившись? Зачастую это просто увеличивает время выполнения и сложность реализации ... но при этом может принести выгоды. Не идентифицируя эти выгоды, вы должны придерживаться нескольких экземпляров, чтобы уменьшить сложность.
• Несколько экземпляров позволяют вашей программе выполнять несколько асинхронных запросов в зависимости от того, что им нужно. Многократные асинхронные запросы хороши (но, очевидно, они будут медленными, если у вас слишком много активных запросов).
• Большинство программ более логичны и просты в обслуживании, когда объекты, от которых они зависят, допускают несколько экземпляров (они не требуют совместного использования).

Предположите несколько экземпляров (1), пока не обнаружите проблему. Даже после того, как проблема обнаружена, вы обычно можете не делиться информацией.

Чтобы определить, что потребляет меньше памяти, требуется гораздо больше информации. Если объекты, которые вы рассматриваете для совместного использования, невелики (очень маловероятно), сами по себе они не являются проблемами с потреблением памяти.

Любой из предложенных подходов может привести к большему потреблению памяти - он полностью зависит от контекста и исполнения. Нам понадобится дополнительная информация, чтобы конкретно ответить на этот вопрос.

Это не означает, что совместное использование является плохим, но совместное использование обычно усложняет ситуацию, потому что вам необходимо спроектировать объекты так, чтобы они вели себя предсказуемо при совместном использовании (особенно если вы работаете в многопоточном контексте).

Задайте себе вопрос:

• Какую значительную (ые) выгоду (а) предоставил бы WebServices?
• Как совместное использование WebServices улучшит вашу программу и уменьшит сложность?

Скорее всего, карта WebServices не взаимодействует с аудио. В этом случае WebServices может быть хорошим кандидатом для базового класса, где аудио и картографические сервисы являются отдельными подклассами (при условии, что класс WebServices уже сложен).