Categories and Delegates and Protocols, Oh My!
If you are like me, fairly early on in your iOS Development career, you may have a running lack of understanding as to what the differences between what Categories, Delegates, and Protocols are. I had learned what a delegates are prior to either of the other two, the definition in my words would be a class that acts on behalf of a certain object, utilizing specific methods to speak to that object in particular. After learning this, and then what a protocol was, I failed to see the difference between the two. Categories did not ease my understanding either.
I wanted to write a quick post about the differences between them to help anyone like me out, those failing to grasp these basic concepts.
Now, my definition of a delegate is not wrong, but it lacks detail. In order for you to fully grasp what it is, I need to first define what a protocol is. A protocol is an interface declaration of specific methods for a class to adopt (i.e. bringing methods from one class into the .m file of another). So say we have an instance of an object that needs to behave in a particular way, “protoObject.” These behaviors would be defined in a specific set of methods that would be included in a protocol. Now, this protocol could be implemented in any class, lets say we have done so in classA, classB, and classC. This would mean that our protoObject could technically be an instance of either classA, classB, or classC. Protocols are a way for objects that are not related by inheritance to communicate.
Delegates on the other hand are “a use of the language feature of protocols” (thanks James Bedford, http://stackoverflow.com/questions/5431413/difference-between-protocol-and-delegates). A delegate is a design pattern of Objective-C where you use protocols where necessary to act on behalf of certain objects. Say you have a View Controller that you are working on, and in this VC you have a UITableView. In order to interact with the TableView and have it conform to the ViewController in a specific way, you would establish your VC as the TableView’s delegate. This way, you can implement the UITableView’s methods in your VC’s class (i.e. cellForRowAtIndexPath).
See the relation?
We know about standard inheritance (subclassing), protocols, (communication w/o inheritance), and delegates (using protocols as necessary). Knowing this, we can define categories with ease. If regular inheritance is vertical, categories would be horizontal inheritance. Essentially, it is the customization of an existing class with other methods. If you wanted to add/change a property or method to and NSArray, you would create a category. As opposed to subclassing, where your new object would inherit all of the properties and behaviors of NSArray.
Other Goodies: KVO vs. NSNotification
I recently learned about what Key-Value Observing was. I know about and use NSNotification’s already, so again I did not entirely see the difference between the two. NSNotifications are events that are broadcasted in your application that can be sent or received using an NSNotificationCenter. You have a sender, that lets the NSNotificationCenter know a specific method was performed, and an observer that listens and performs an action depending on what the NSNotificationCenter receives.
KVO on the other hand, listens for changes to a specific object (such as one of its properties being altered) and performs an action when the change occurs.