Объективная-c асинхронная передача: цель/действие или шаблон делегации?

Я справляюсь с некоторыми ситуациями с асинхронной передачей (Событийно-ориентированный парсинг XML, обработка ответа NSURLConnection, и т.д.). Я попытаюсь кратко объяснить свою проблему:

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

Я пытаюсь найти, что своего рода шаблон или эмпирическое правило реализуют такого рода вещи, и я вижу 3 возможных решения:

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

2. Используйте подход цели/действия: клиент просит, чтобы поставщик услуг выполнил задачу и передал селектор, который должен будет быть вызван поставщиком услуг, как только это закончило задачу.

3. Используйте уведомления.

(Обновление) Через некоторое время попытки решения № 2 (цель и действия), я пришел к выводу, что в моем случае лучше использовать подход делегации (#1). Вот за и против каждой опции, поскольку я вижу их:

Подход делегации:

• 1 (+) позитивный аспект опции 1 - то, что мы можем проверить на ошибки времени компиляции, потому что клиент должен реализовать протокол делегата поставщика услуг.

• 1 (-) Это - также оборотная сторона, потому что она заставляет клиент быть трудным - вместе с поставщиком услуг, поскольку она должна реализовать свой протокол делегата.

• 1 (+) Это позволяет программисту легко просматривать код и находить, какой метод клиента, поставщик услуг вызывает для передачи его результатов.

• 1 (-) С клиентской точки зрения, не то, чтобы легкий найти, какой метод будет вызван поставщиком услуг, как только это имеет результаты. Это все еще легко, просто перейдите к методам протокола делегата и вот именно, но подход № 2 является более прямым.

• 1 (-) Мы должны написать больше кода: Определите протокол делегата и реализуйте его.

• 1 (-) кроме того, шаблон делегации должен использоваться, действительно, для делегирования поведения. Этот сценарий не был бы точным случаем делегации, семантически говоря.

Подход действия/Цели

• 2 (+) позитивный аспект опции 2 - то, что, когда метод поставщика услуг называют, @selector, определяющий действие обратного вызова, должен также быть определен, таким образом, программист знает тут же, какой метод будет вызван назад для обработки результатов.

• 2 (-) Против этого, трудно найти, какой метод будет призван обратно в клиенте при просмотре кода поставщика услуг. Программист должен перейти к сервисному вызову и видеть, какой @selector проводится.

• 2 (+) Это - более динамическое решение и вызывает меньше связи между частями.

• 2 (-), Возможно, одна из самых важных вещей: Это может вызвать ошибки времени выполнения и побочные эффекты, поскольку клиент может передать селектор, который не существует поставщику услуг.

• 2 (-) Используя простой и стандартный подход (#performSelector:withArgument:withArgument:) поставщик услуг может только передать до 2 аргументов.

Уведомления:

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

Заключение: На данном этапе я выбрал бы механизм делегации. Этот подход обеспечивает больше безопасности и позволяет легко просматривать код для следования за последствиями отправки делегату результатов действий поставщика услуг. Отрицательные аспекты об этом решении то, что: это - более статическое решение, мы должны написать больше кода (Связанный с протоколом материал) и, семантически разговор, мы не говорим действительно о делегации, потому что поставщик услуг ничего не делегировал бы.

Я пропускаю что-то? что Вы рекомендуете и почему?

Спасибо!