Singleton with a delegate: Good idea or bad?

Question

I have created objects that are interfaces to a web service. One typical object would be a "TaskService". When a client uses one of these objects, it invokes one of the service's methods (such as "GetTasks") and the service will asynchronously go off to call the remote web service, and post back the retrieved data via a delegate.

Currently, to use one of these services you have to create it with [[TaskService alloc] init], but I decided it makes more sense to make each service into a singleton object.

Is it common to see singleton objects that hold reference to delegates? My main issue with the design, is that each object, whenever it requires use of a particular service, will have to set itself as the delegate before invoking the service, which doesn't seem quite right to me... What if another object were to set itself as the delegate inbetween you setting yourself as the delegate and invoking the service?

Many thanks in advance!

Regards, Nick

Answer 1

Imo this is not a good idea for the reason you cited. The Singleton pattern is really for things there are only one of, but it sounds like your app can have need for multiple instances of these services. I think you'd wind up working around this (using an operations queue or some kind of delegate multiplexer) when you really just need to instantiate multiple instances of your service.

Answer 2

The scope of a singleton is entire application. For example: Let consider the example of shopping application the logger data, about the user ID which need to be accessible on different part of application like order, payment, cart etc.

Delegates are used for 1 to 1 communication, for example: You can take as example You have two classes TV and remote control device. You want to change the channel of TV. Delegate methods of TV for changing channel are implemented in remote control device class. So you use remote control device and you change the channel of the TV.

The singleton is used to communicate with multiple receivers, while the delegation pattern is used usually for 1 to 1 communication.

Answer 3

When the occasion warrants the use of a Singleton object, I always avoid delegation for the reason you cite. Consumers of a singleton can't know (without some ugly coding) if they're stepping on some other consumer's toes by setting themselves as the one-and-only delegate of the singleton. NSNotifications are a much cleaner tool for the job; any arbitrary number of listeners can consume the notifications without caring who else may be listening.

Delegation works best when there is clear ownership between the classes. Nobody owns a singleton.

Answer 4

Singleton isn't really the problem, you cause the same sort of issues by simply instancing a class and passing it about as a global variable. As other's have mentioned a queue is a possibility, or when you invoke a task on a service in your Singleton have it instance a TaskRequest object passing in the method and the call back delegate, that way requests can't trample on each other. In fact it would be a good idea to do that with a queue anyway.