Search

Protocols, part 1 : Why?

Mark Dalrymple

2 min read

Apr 8, 2012

Protocols, part 1 : Why?

A comment from a reader of Objective-C Programming: The Big Nerd Ranch Guide came through on the forums, asking about Objective-C protocols. Specifically, why do we need them? Why do they exist?

As a reminder, a protocol is a list of methods that’s been given a name. The NSCopying protocol contains a single method copyWithZone:, while the NSCoding protocol contains encodeWithCoder: and initWithCoder:. You adopt a protocol by adding the protocol name in angled brackets after the class you’re inheriting from:

@interface BNRGroovyness : NSObject <NSCoding>

This @interface says that “BNRGroovyness inherits (is-a) NSObject, and so can be used anywhere an NSObject can be used. And also, it promises to implement the required methods in the NSCoding protocol.” The compiler will check your work to make sure you actually implement them. Of course, you don’t have to implement optional methods in the protocol unless you really want to.

Like many programming constructs, protocols are primarily a communication mechanism. They communicate to the compiler that these objects really can receive a particular set of messages. They also communicate to the reader of the code that this class has some higher-level semantics. “This class conforms to NSCoding, therefore I can encode and decode its objects into a data archive” or “Oh! This class conforms to UITableViewDataSource! I can use its objects to power a table view.” Xcode can also use protocol adoption to expand the list of autocomplete options, making it easier to correctly spell the names of the methods you’d be implementing.

Protocols allow for a kind of multiple inheritance in Objective-C. You don’t really inherit code from multiple classes, but you can inherit multiple contracts, stating that you’ll obey those contracts. If you’ve used Java, they’re just like Java interfaces, which interestingly enough were inspired by Objective-C protocols. So when you’re adopting multiple protocols, all the code is implemented in your class or comes via the single-inheritance chain.

Protocols come into their own when you’re handing an object to another object for it to do work. If you’re giving an object to an NSKeyedArchiver, that object needs to support NSCoding so that the archiver can serialize the object. If you’re giving an object to a UITableView, it needs to support UITableViewDataSource so that it can feed the table. This helps move some of the correctness tests from run-time (“oops, this object doesn’t implement -encodeWithCoder: . Time to crash!”) to compile time ("warning: sending 'BNRGroovyness *' to parameter of incompatible type: id<NSCoding>")

One very popular use for making your own protocols is setting up a delegate relationship between objects. Come back next time for details.

Mark Dalrymple

Author Big Nerd Ranch

MarkD is a long-time Unix and Mac developer, having worked at AOL, Google, and several start-ups over the years.  He’s the author of Advanced Mac OS X Programming: The Big Nerd Ranch Guide, over 100 blog posts for Big Nerd Ranch, and an occasional speaker at conferences. Believing in the power of community, he’s a co-founder of CocoaHeads, an international Mac and iPhone meetup, and runs the Pittsburgh PA chapter. In his spare time, he plays orchestral and swing band music.

Speak with a Nerd

Schedule a call today! Our team of Nerds are ready to help

Let's Talk

Related Posts

We are ready to discuss your needs.

Not applicable? Click here to schedule a call.

Stay in Touch WITH Big Nerd Ranch News