(ConformsToProtocol: && RespondsToSelector :) vs just (answered by SoSelector :)

Question

If you want to call the protocol method for a delegate object that, I hope, implements the corresponding protocol method, I see that the developers first check

if([delegate respondsToSelector: @selector(aMethod)]) { //send message; } 

Is it not better or even safer to do this?

 if([delegate conformsToProtocol:@protocol(MyProtocol)] && [delegate respondsToSelector: @selector(aMethod)]) { //send message; } 

I know that if the protocol method definitions were properly structured, the delegate should never have conflicts or implementations that cannot be intended for / from MyProtocol. Such conflicts are far away, but I came across a protocol method definition that is simply declared as - (void) willStartLogin ;. I am sure that you can already start thinking and suggesting how such a protocol method is bad, it can, for example, be implemented by a delegate for personal / internal use, and not for use in accordance with the myDelegate protocol. It would be better to declare the MyProtocol method like this: - (void) myObjectWillStartLogin: (MyObject *) myObjectInstance; to get rid of any ambiguity and make things obvious.

I hope that I will not miss anything that forces me to check only the responses to the request: Thank you

Answer 1

If the object absolutely must comply with the protocol, you must declare your object in this way:

 id<MyProtocol> delegate; 

This will create compile-time errors for those trying to assign an object that does not conform to the MyProtocol protocol to the MyProtocol variable / parameter / property. (They can use explicit casts to circumvent the warning, but it is for them to do this wisely.)

You still need to check the respondsToSelector , just in case the delegate will respond to the selector, as there are several ways it might not work. (Hat tip: @Hot Licks)

Answer 2

I'm not quite sure what you are asking, but maybe this will help:

A protocol is a set of methods, some of which are necessary, some optional. The answer to the question conformsToProtocol: is whether an object implements a bunch of methods - required - and may implement some others - optional. Note that it claims to be here, and not because refusing to implement the required method does not prevent compilation (this is just a warning).

The answer to the question respondsToSelector: is whether the object implements a specific method. This gives the final answer for this particular method, unlike conformsToProtocol:

The defining nature of respondsToSelector: is why it is commonly used.

You might think that checking the protocol in addition to the method is better, since it implies a higher probability that the method will do what you expect, and if so, using both respondsToSelector: and conformsToProtocol: you will answer you search ... it seems like the protocols are just the names of the methods and signatures, the behavior of these methods is implied, and not forced (*).

NTN.

(* if you want forced contracts to look, for exmaple, Eiffel)