It sort of depends on how you want to use it once you've made it. If you want to use a subclass you've created, you'll have to be responsible for allocating instances of it. But there are times when you'd like to extend a class where you typically aren't allocating the instances you want to be able to use your new methods on. For those times, use a category -- it adds methods to every instance of the class, not just the ones you allocate yourself.
For example, in our open-source OmniFoundation framework, we define about twenty additional methods for NSArray. Many of them are conveniences that let you perform common tasks in one method call instead of writing the same ten lines of code over and over (like -reversedArray or -randomObject). If these methods were implemented in a subclass, we'd have to create an instance of that subclass any time we wanted to use them -- since a bunch of Apple APIs return NSArrays, it'd be a pain to do [[OFArray alloc] initWithArray:anArray] every time we wanted to use one of our extension methods on one.
Also, in some cases you might want to extend the behavior of objects where it's impossible to allocate them yourself. For example, in OmniAppKit we extend NSColor to provide a property list representation of itself -- this lets us easily save color references in NSUserDefaults for any color the user can pick in the color panel. If we wanted to do that with an NSColor subclass, we'd also have to sublcass NSColorPanel and/or all the pickers inside it (most of which are private Apple classes) to provide instances of our subclass instead of NSColors.
Top
