The setup: I have a singleton data access manager object, call it Manager. I also have some view controllers, call them Apples and Oranges. Both Apples and Oranges use Manager for some shared data model/access functionality.
I would like Manager to call either of them back in certain cases according to something like this:
if (someCondition)
[self.applesDelegate callSomething];
else if (otherCondition)
[self.orangesDelegate callSomething];
I see three ways of implementing this, none of which I am happy with.
1) do exactly as I did above, give Manager some properties like applesDelegate and orangesDelegate, and have relevant view controllers register themselves for that. But that would be bad because Manager would have domain knowledge, and I don't want to have that. Manager shouldn't know anything about Apple or Orange objects.
2) have a dynamic delegates map. Manager would have some NSMutableDictionary for delegates, and Apples and Oranges would do something like
[manager.delegateMap setObject:self forKey:@"applesDelegate"];
And Manager, when it would need to call the delegates, would do something like
if (someCondition) {
[[delegatemap objectForKey:@"applesDelegate"] callSomeMethod];
}
This sounds workable but strange. And I'm not sure how it would work with the common dealloc requirement of setting the delegate to nil when you don't have a delegate property but this kind of indirection.
3) give up on the idea of delegates altogether and use notifications instead. Manager would just generate notifications and Apples and Oranges would listen to those. This loses a lot of compile-time checks though, this is why I'm still thinking about delegates that have a bit tighter coupling.
Which of the three would you recommend here? Or perhaps something different?