( ConformsToProtocol: && RespondsToSelector: ) vs just ( respondsToSelector: )

Question

When wanting to call a protocol method on a delegate object that, hopefully, implements the respective protocol method, I see developers first checking

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

Is it not better or even safer to do this instead ? :

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

I know that if the protocol method definitions have been structured properly then there should never be any conflicts or implementations in the delegate that may not be intended for / come from MyProtocol. Such conflicts are far fetched but I have come across a protocol method definition simply declared as -(void)willStartLogin;. Im sure you can already start thinking and suggesting how such a protocol method is bad, it could for example have been implemented by the delegate for personal / internal use and not for use under the myDelegate protocol. It would be better to declare MyProtocol's method as so: -(void)myObjectWillStartLogin:(MyObject*)myObjectInstance; so as to get rid of any ambiguity and make things obvious.

I hope I am not missing anything that makes it only necessary to check respondsToSelector: Thank you

Though you are correct that there is some danger of accidentally invoking a method not meant for the current delegate pattern, even some of the Cocoa classes don't check both "conforms" and "responds". It all depends on how paranoid you want to be. Personally, I generally have other alligators to wrestle with. — Hot Licks, Dec 05 '13 at 01:36
I think most of library only use `respondsToSelector:`. `conformsToProtocol:` should be checked at compile time — Bryan Chen, Dec 05 '13 at 01:40
I believe that Cocoa and Cocoa Touch frameworks never check conformance to protocols -- only response to selectors. — newacct, Dec 05 '13 at 10:05

score 7 · Answer 1 · answered Dec 05 '13 at 01:46

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

A protocol is a collection of methods, some required, some optional. The question answered by conformsToProtocol: is whether an object claims to implement a bunch of methods - the required ones - and may implement some others - the optional ones. Note that it is claims to here, rather than does, as failure to implement a required method does not prevent compilation (it is just a warning).

The question answered by respondsToSelector: is whether an object implements a particular method. This provides a definitive answer for this particular method, unlike conformsToProtocol:.

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

You may be thinking that checking for the protocol in addition to the method is better as it implies a stronger likelihood that the method does what you expect, and if so using both respondsToSelector: and conformsToProtocol: tells you the answer you seek... sort of - as protocols really are just method names and signatures, the behaviour of those methods being implied rather than enforced(*).

HTH.

(* if you want enforced contracts look at, for exmaple, Eiffel)

thanks for your answer. I Do know that conformsToProtocol does not check if the protocol methods have been implemented. But my question was that: is it not better to, on top of respondsToSelector, check if the target responds to the selector because it conforms to the protocol. It might respond because it conforms to another protocol with exactly the same method, or maybe just a coincidence. This is ofcoz highly unlikely because if [delegate RTS: sel]=YES it means we would have done e.g: engine.delegate = self; which means we want to receive messages from engine. Hope I'm making sense. — pnizzle, Dec 05 '13 at 04:21

godel9 · Accepted Answer · 2013-12-05T02:00:01.183

4

If an object absolutely must conform to a protocol, then you should declare your object this way:

id<MyProtocol> delegate;

This will generate compile-time errors for anyone trying to assign an object that doesn't conform to the MyProtocol protocol to the variable/parameter/property delegate. (They can use an explicit cast to get around the warning, but it's up to them to do that intelligently.)

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

edited Dec 05 '13 at 02:00

answered Dec 05 '13 at 01:45

godel9

7,340
1
33
53

And it's absolutely impossible to get the wrong object type assigned to a pointer, right? – Hot Licks Dec 05 '13 at 01:48
@HotLicks You're correct that you still need to check `respondsToSelector` to prevent a possible run-time exception. – godel9 Dec 05 '13 at 01:58
@godel9 perfect. I eventually remembered over lunch that if the delegate property is not nil it means we would somewhere have set the delegate meaning we want to receive the messages/method calls declared by the protocol. And as you noted, a warning would come up if the the object being set as the delegate does not conform to the protocol. So I guess respondsToSelector does the trick, though checking for both also doesn't harm any logic. – pnizzle Dec 05 '13 at 04:27
@godel9 would you please give example of other ways that the delegate might not respond to the selector except for run time issue? – allenlinli Mar 11 '17 at 03:51
Here is a good example of "informal protocol": http://stackoverflow.com/questions/2010058/informal-protocol-in-objective-c – allenlinli Mar 11 '17 at 03:52

( ConformsToProtocol: && RespondsToSelector: ) vs just ( respondsToSelector: )

2 Answers2