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
The truth is that singletons aren't inherently bad if they're used correctly. The goal of the singleton pattern is to ensure only one instance of a class is alive at any one time. That, however, is not the goal many developers have in mind when using singletons.
Criticism. Critics consider the singleton to be an anti-pattern as it introduces global state into an application, often unnecessarily. This in turn can place restrictions on any abstraction that uses the singleton, for example by preventing concurrent use of multiple instances.
A singleton should be used when managing access to a resource which is shared by the entire application, and it would be destructive to potentially have multiple instances of the same class. Making sure that access to shared resources thread safe is one very good example of where this kind of pattern can be vital.
Disadvantages of a Singleton PatternUnit testing is more difficult (because it introduces a global state into an application). This pattern reduces the potential for parallelism within a program, because to access the singleton in a multi-threaded system, an object must be serialized (by locking).
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With