tags:

views:

1456

answers:

4

Can some one explain to me the difference between categories and inheritance in Objective C? I've read the entry in wikipedia and the discussion on categories there doesn't look any different to that of inheritance. I also looked at the discussion on the topic in the book "Open Iphone Development" and I still don't get it.

I might be missing something very obvious so please bear with me.

+5  A: 

Categories allow you to add methods to existing classes. So rather than subclass NSData to add your funky new encryption methods, you can add them directly to the NSData class. Every NSData object in your app now has access to those methods.

To see how useful this can be, look at: CocoaDev

Terry Wilcox
are you sure that just by making a category out of NSData everywhere NSData is used the category is used, I thought you need to make the category pose as NSData for it to be used instead of NSData
hhafez
It doesn't automatically apply to NSData objects, you still need to #import the header where you define the category.
Abizern
No, classes pose. All NSData objects get the methods of categories that are loaded.
Chuck
And it doesn't matter if you import the header — the objects still get the method. The compiler will complain if you try to call it directly, but you can still call it with performSelector:.
Chuck
A category is not a class; it doesn't replace the existing class. It adds methods to the existing class.
Terry Wilcox
+1  A: 

A Category is like a mixin: a module in Ruby, or somewhat like an interface in Java. You can think of it as "naked methods". When you add a Category, you're adding methods to the class. The Wikipedia article has good stuff.

Charlie Martin
but you are still making a new class aren't you? So what is the difference between that and inheritance
hhafez
No, you are not making a new class. You are adding methods to an existing class.
Chuck
+5  A: 

Sometimes, inheritance just seems like more trouble than it is worth. It is correctly used when you want to add something to an existing class that is a change in the behaviour f that class.

With a Category, you just want the existing object to just do a little more. As already given, if you just want to have a string class that handles compression, you don't need to subclass the string class, you just create a category that handles the compression. That way, you don't need to change the type of the string classes that you already use.

The clue is in the restriction that categories only add methods, you can't add variables to a class using categories. If the class needs more properties, then it has to be subclassed.(edit: you can use associative storage, I believe).

Categories are a nice way to add functionality while at the same time conforming to an object oriented principle to prefer composition over inheritance.

Abizern
It should be noted, you *can* declare properties for existing ivars with Categories. By that I mean, you can declare an `@property` and either `@synthesize` or `@dynamic` them in the implementation. I have done this with `readonly` properties, although I imagine they could be used for anything. That is, assuming `MyClass` has `int myVar`, then `MyClass (MyCategory)` can have a property for `myVar`.
jbrennan
True, but that still doesn't _add_ storage to the class.
Abizern
A: 

One of favorite illustrations of Objective-c categories in action is NSString. NSString is defined in the Foundation framework, which has no notion of views or windows. However, if you use an NSString in a Cocoa application you'll notice it responds to messages like – drawInRect:withAttributes:.

AppKit defines a category for NSString that provides additional drawing methods. The category allows new methods to be added to an existing class, so we're still just dealing with NSStrings. If AppKit instead implemented drawing by subclassing we'd have to deal with 'AppKitStrings' or 'NSSDrawableStrings' or something like that.

Categories let you add application or domain specific methods to existing classes. It can be quite powerful and convenient.

amrox