What is the difference between inheritance and Categories in Objective-C

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 of that class.

With a Category, you just want the existing object to 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.

Edit January 2012

Things have changed now. With the current LLVM compiler, and the modern, 64-bit runtime, you can add iVars and properties to class extensions (not categories). This lets you keep private iVars out of the public interface. But, if you declare properties for the iVars, they can still be accessed / changed via KVC, because there is still no such thing as a private method in Objective-C.

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

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.

If you as a programmer are given a complete set of source code for a code library or application, you can go nuts and change whatever you need to achieve your programming goal with that code.

Unfortunately, this is not always the case or even desirable. A lot of times you are given a binary library/object kit and a set of headers to make do with.

Then a new functionality is needed for a class so you could do a couple of things:

1. create a new class whole instead of a stock class -- replicating all its functions and members then rewrite all the code to use the new class.

2. create a new wrapper class that contains the stock class as a member (compositing) and rewrite the codebase to utilize the new class.

3. binary patches of the library to change the code (good luck)

4. force the compiler to see your new class as the old one and hope it does not depend on a certain size or place in memory and specific entry points.

5. subclass specialization -- create subclasses to add functionality and modify driver code to use the subclass instead -- theoretically there should be few problems and if you need to add data members it is necessary, but the memory footprint will be different. You have the advantage of having both the new code and the old code available in the subclass and choosing which to use, the base class method or the overridden method.

6. modify the necessary objc class with a category definition containing methods to do what you want and/or override the old methods in the stock classes.

   This can also fix errors in the library or customize methods for new hardware devices or whatever. It is not a panacea, but it allows for class method adding without recompiling the class/library that is unchanged. The original class is the same in code, memory size, and entry points, so legacy apps don't break. The compiler simply puts the new method(s) into the runtime as belonging to that class, and overrides methods with the same signature as in the original code.

   an example:

   You have a class Bing that outputs to a terminal, but not to a serial port, and now that is what you need. (for some reason). You have Bing.h and libBing.so, but not Bing.m in your kit.

   The Bing class does all kinds of stuff internally, you don't even know all what, you just have the public api in the header.

   You are smart, so you create a (SerialOutput) category for the Bing class.

   [Bing_SerialOutput.m]
   @interface Bing (SerialOutput)   // a category
   - (void)ToSerial: (SerialPort*) port ;
   @end
   
   @implementation Bing (SerialOutput)
   - (void)ToSerial: (SerialPort*) port 
   {
   ... /// serial output code ///
   }
   @end
   

   The compiler obliges to create an object that can be linked in with your app and the runtime now knows that Bing responds to @selector(ToSerial:) and you can use it as if the Bing class was built with that method. You cannot add data members only methods and this was not intended to create giant tumors of code attached to base classes but it does have its advantages over strictly typed languages.