1

I'm reading up on protocols (and thinking I might be able to rewrite some code using them) but I seem to be getting stuck on what exactly makes it different than a class?

For example, if I have a class ColorController:

#import <Foundation/Foundation.h>

@interface ColorController : NSObject { 

UIColor* colorToReturn;

}


- (UIColor* ) setColor : (float) red : (float) green : (float) blue; 

@end

and the .m

#import "ColorController.h"

@implementation ColorController 


- (UIColor* ) setColor : (float) red : (float) green : (float) blue { 

float newRed = red/255;
float newGreen = green/255;
float newBlue = blue/255;

colorToReturn = [UIColor colorWithRed:newRed green:newGreen blue:newBlue alpha:1.0];

return colorToReturn;
}
@end

and then import it into another class:

ColorController* colorManager = [ColorController new]; 

UIColor* newColor = [colorManager setColor:66.0:66.0:66.0];

this seems to make perfect sense to convert into a protocol, since a lot of other classes could use the setColor method. But I am not sure if my understanding of protocols is off, I thought that once a protocol was declared it would be available to other classes, but since you have to still include it in the .h files, the only discernible difference to me was that with a protocol the setColor method could be called directly in whatever class I have imported the protocol to, whereas with importing a class I would have to call back to the class and method [colorManager setColor:66.0:66.0:66.0]; What exactly would be the gain here?

Now my view is probably because I'm a newbie/inexperienced with protocols and have a limited view on them and their usage so if someone could give me a brief (other than "go read the docs" : D ) reply on the benefits of protocols and maybe an example of use I'd really appreciate it.

PruitIgoe
  • 6,166
  • 16
  • 70
  • 137
  • the protocols are for the delegation pattern. you don't look such person whom wants to make a delegate class for `ColorController`, but in your case you can make some class-method instead of instance-method for the `-setColor:red:green:`. furthermore I would recommend you to refactor this method like: `-colorWithRed:andGreen:andBlue:`. – holex Jul 20 '12 at 16:09
  • 2
    possible duplicate of [What is the point of Protocols?](http://stackoverflow.com/questions/5881163/what-is-the-point-of-protocols), [What is a protocol?](http://stackoverflow.com/questions/3981832/what-is-a-protocol), [ObjC Protocols usage](http://stackoverflow.com/questions/7617615/objective-c-protocols-usage) – jscs Jul 20 '12 at 18:00

2 Answers2

2

A protocol does not give an implementation, only a declaration of some functionality. You would still have to implement the function(s) manually for any class that conforms to that protocol. (A common example of this is the delegate pattern). Protocols are similar to interfaces in java, if you are familiar to those.

edit removed dead link

Dima
  • 23,484
  • 6
  • 56
  • 83
  • 1
    I heart the cups of cocoa site, lots of good stuff there. Thanks for the link. – PruitIgoe Jul 20 '12 at 16:06
  • And hey, SO, is it to much to ask for target="_new" on all the links so I can toggle between pages? : ) – PruitIgoe Jul 20 '12 at 16:06
  • Looks like you're out of luck with [that one](http://meta.stackexchange.com/questions/35677/have-all-links-open-in-a-new-tab). :-P. For what it's worth, when I want to do that.. I just use middle-click to open links. – Dima Jul 20 '12 at 16:11
1

And ObjC protocol is a lot like a Java interface: - you don't have to implement your protocol - a class can implement more than one protocol, but only be subclassed from one class

So if you expect your class-or-protocol will only be used by one class, a subclass which inherits much of your behavior, then make a class. But if you expect more than one class to use your class-or-protocol, then make a protocol.

Yusuf X
  • 14,513
  • 5
  • 35
  • 47