NSNotifications vs delegate for multiple instances of same protocol

Question

I could use some architectural advice. I've run into the following problem a few times now and I've never found a truly elegant way to solve it.

The issue, described at the highest level possible:
I have a parent class that would like to act as the delegate for multiple children (all using the same protocol), but when the children call methods on the parent, the parent no longer knows which child is making the call.

I would like to use loose coupling (delegates/protocols or notifications) rather than direct calls. I don't need multiple handlers, so notifications seem like they might be overkill.

To illustrate the problem, let me try a super-simplified example:
I start with a parent view controller (and corresponding view). I create three child views and insert each of them into the parent view. I would like the parent view controller to be notified whenever the user touches one of the children. There are a few options to notify the parent:

1. Define a protocol. The parent implements the protocol and sets itself as the delegate to each of the children. When the user touches a child view, its view controller calls its delegate (the parent). In this case, the parent is notified that a view is touched, but it doesn't know which one. Not good enough.

2. Same as #1, but define the methods in the protocol to also pass some sort of identifier. When the child tells its delegate that it was touched, it also passes a pointer to itself. This way, the parent know exactly which view was touched. It just seems really strange for an object to pass a reference of itself.

3. Use NSNotifications. The parent defines a separate method for each of the three children and then subscribes to the "viewWasTouched" notification for each of the three children as the notification sender. The children don't need to attach themselves to the user dictionary, but they do need to send the notification with a pointer to themselves as the scope.

4. Same as #4, but rather than using separate methods, the parent could just use one with a switch case or other branching along with the notification's sender to determine which path to take.

5. Create multiple man-in-the-middle classes that act as the delegates to the child views and then call methods on the parent either with a pointer to the child or with some other differentiating factor. This approach doesn't seem scalable.

Are any of these approaches considered best practice? I can't say for sure, but it feels like I'm missing something more obvious/elegant.

Answer 1

Your #2 is the standard Cocoa pattern for delegates. Each message of the delegate protocol takes the object as the first argument. For example, in UITableViewDelegate, you find methods like this:

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath;

When a table view sends this message to its delegate, it sends itself (the table view) as the first argument. If the delegate object is the delegate of multiple table views, it can use the first argument to figure out which table view sent the message.

When there are no other arguments, the message still takes the object as an argument, as in this UITableViewDataSource method:

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView;

You will find this pattern all over the Cocoa Touch framework; UIPickerViewDelegate, UIImagePickerControllerDelegate, and UINavigationControllerDelegate are just a few examples.

You should follow the standard pattern unless you have a compelling reason not to. Following the convention will make it easier for others (and future you) to understand your code.