Adopting two protocols with same method signature

Standard practice is to pass the object calling the delegate. Then the delegate method can inspect that object to determine what action it needs to perform.

First of all, it is important to get your nomenclature correct. That which you have named "Delegate" is actually a protocol. If you don't name your identifiers properly, you will get confused and stay confused because you will attribute some inherent quality to that object based on the name you have arbitrarily assigned. It should be written like so:

@protocol doSomethingProtocol
- (void) doSomething;
@end

Now, as far as reusing the same protocol signatures for different protocols - just don't do it.

@protocol doSomethingElseProtocol

- (void) doSomethingElse;

@end

Now, to get to your original question. How does Apple implement their own protocols? They pass a context parameter. A good protocol would look something like:

@protocol doSomethingProtocol

- (void) doSomethingWith: (id) object;

@end

Then, in your delegate, you could implement that with:

@implementation MyDelegate <doSomethingProtocol>

- (void) doSomethingWith: (id) object
{
if(object == myObject1)
{
// Do something.
}
else if(object == myObject2)
{
// Do something else.
}
}

@end
{code}

m_userName wrote:
Ok, I take your point about not having two unrelated protocols with the same method signature. It's not something I'd do myself, I was more wondering in case you were using a code library and there was a name method signature clash with your own code.

That can be a problem. The only practical solution is to change the name of your own identifier. C++ tried to introduce namespaces, but most people just do a "using namespace" anyway.

However, I'm still confused about what you have written about the delegate actually being a protocol. I thought DelegateA was a protocol which was also a delegate, so I think I'm confused about the nomenclature of when "delegate" and "protocol" are used.

A protocol is a formal interface that can be adopted by a class without having to impose any class hierarchy. It is a more elegant solution than multiple inheritance.

A delegate is an object that can take actions on behalf of some other object. It is a software design pattern to avoid having to create complex class hierarchies.

A delegate must conform to some protocol, formal or not, in order for the referencing object to know what methods to call on it. You don't need to use a delegate to use a protocol, but they are often used together.

Is a delegate a protocol that make sure one class can delegate an action to another class which implements that protocol

No.

or is it a class which implements a protocol that allows another class to delegate actions to it?

Yes, exactly.

It make clarify, it might help to think of a concrete example such as the UITableView class. The reference documentation says that "the delegate of a UITableView object must adopt the UITableViewDelegate protocol". I imagine that this is implemented something like:
...
If this assumption is correct, it seems similar to my example in that DelegateA, ClassA, and TestClass are interchangeable with UITableViewDelegate, UITableView and MyController respectively. But from what you've said, DelegateA is a protocol, not a delegate, and so should actually be called ProtocolA?

That is just unfortunately poor naming on Apple's part. It is one of those things you can't call useless, because it can always be used as a bad example. This bad example proves my point about having accurate identifier names to avoid confusion. Apple didn't do that and you are confused. I don't blame you.

UITableViewDelegate is not a delegate. It is a protocol.

If an object whose class conforms to the "UITableViewDelegate" protocol is assigned to the delegate pointer of another object, that object is a delegate. The only thing that can be a "delegate" is an object that is assigned as such.

The only way that a formal protocol is involved is that it can force you to only assign, as a delegate, an object of a class that implements said protocol. Most delegates in MacOSX use informal protocols. This means that the delegate is just an instance of the generic "id" class. The calling object uses runtime inspection methods to determine if the delegate really can perform the actions it needs the delegate to take.