Синглтон с делегатом: хорошая идея или плохая? - PullRequest
5 голосов
/ 01 февраля 2012

Я создал объекты, которые являются интерфейсами к веб-сервису.Одним типичным объектом будет «TaskService».Когда клиент использует один из этих объектов, он вызывает один из методов службы (например, «GetTasks»), и служба асинхронно отключается, чтобы вызвать удаленный веб-сервис и отправить обратно полученные данные через делегата.

В настоящее время, чтобы использовать один из этих сервисов, вы должны создать его с помощью [[TaskService alloc] init], но я решил, что более разумно превратить каждый сервис в одноэлементный объект.

Распространено ли этоувидеть одноэлементные объекты, которые содержат ссылку на делегатов?Моя главная проблема с дизайном, это то, что каждый объект, когда ему требуется использование определенного сервиса, должен будет установить себя в качестве делегата перед вызовом сервиса, что мне не совсем подходит ... Что если другой объектдолжны были установить себя в качестве делегата между вами, установить себя в качестве делегата и вызвать службу?

Заранее большое спасибо!

С уважением, Ник

Ответы [ 4 ]

4 голосов
/ 01 февраля 2012

Когда случай требует использования объекта Singleton, я всегда избегаю делегирования по той причине, на которую вы ссылаетесь. Потребители синглтона не могут знать (без некрасивого кодирования), наступают ли они на пальцы других потребителей, устанавливая себя в качестве единственного и единственного делегата синглтона. NSNotifications гораздо более чистый инструмент для работы; Любое произвольное количество слушателей может потреблять уведомления, не заботясь о том, кто еще может их слушать.

Делегирование работает лучше всего, когда между классами существует четкое владение. Никто не владеет синглтоном.

4 голосов
/ 01 февраля 2012

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

0 голосов
/ 15 сентября 2017

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

Делегаты используются от 1 до 1Связь, например: Вы можете взять в качестве примера У вас есть два класса телевизора и устройства дистанционного управления.Вы хотите изменить канал ТВ.Методы делегирования ТВ для смены канала реализованы в классе устройств дистанционного управления.Таким образом, вы используете устройство дистанционного управления и меняете канал телевизора.

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

0 голосов
/ 01 февраля 2012

Синглтон на самом деле не проблема, вы вызываете такие же проблемы, просто создавая экземпляр класса и передавая его как глобальную переменную. Как уже упоминалось другими, очередь возможна, или когда вы вызываете задачу в службе в вашем Singleton, он имеет экземпляр объекта TaskRequest, передающий метод и делегат обратного вызова, таким образом, запросы не могут попирать друг друга. На самом деле было бы неплохо сделать это с очередью.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...