Categories on NSObject -- keeping it safe

Question

Categories of the Root Class

A category can add methods to any class, including the root class. Methods added to NSObject become available to all classes that are linked to your code. Adding methods to the root class with a category can be useful at times, but it can also be quite dangerous. Although it may seem that the modifications the category makes are well understood and of limited impact, inheritance gives them a wide scope. You may be making unintended changes to unseen classes in your application; you may not know all the consequences of what you’re doing. Moreover, others working on your application, who are unaware of your changes, won’t understand what they’re doing.

My question is -- if I choose method names that are sufficiently weird that I am quite sure that no one else will use them (either at Apple or in my project), can I still get into trouble? Could there still be unexpected behavior? Performance implications?

Objective-C would prefer you subclass. But, playing it safe is for losers, right? ;) — Patrick Perini, Jul 14 '11 at 13:11

score 9 · Accepted Answer · edited May 14 '15 at 10:47

9

If you're really quite certain that Apple would never add a method of that name, it's safe. If you want to enforce that certainty though, prefix the selector name. For example, Adium at one point added a -setObject:atIndex: method to NSMutableArray (yes, just a "cosmetic" wrapper over the existing API method -replaceObject:atIndex. Very pointless)... it turned out to have the same name as an internal method, and veeeeery slightly different semantics. This caused crashes, but only on certain OSs. If it had been named something like -AISetObject:atIndex:it would have been fine.

Performance implications for categories are minimal. I wouldn't worry about that aspect.

edited May 14 '15 at 10:47

KlimczakM

12,576
11
64
83

answered Jul 14 '11 at 16:04

Catfish_Man

41,261
11
67
84

3

It’s not just the system. One crash report in a category method `-[NSDictionary setDoubleValue:forKey:]` turned out to be a conflict with an input manager which implemented a method with the same name but apparently expecting an object as the Double: parameter. The input manager was being used to inject code into iChat, but apparently loaded the full hack into every app, including its Foundation categories. – Jens Ayton Jul 14 '11 at 16:42
I guess AISetObject wouldn't have been very "cosmetic" anymore :-) – Joris Weimar May 15 '12 at 19:05

score 1 · Answer 2 · answered Jul 14 '11 at 13:50

If your method names do not conflict with anything, and people who use them know what they do, you shouldn't run into any problems. Remember, a category adds extra methods, but not instance variables to a class. A subclass is more flexible, and is treated as an entire object, which responds to all superclass methods plus it's own. I would say make a subclass unless you can't or it's inconvenient to do so. Categories were made to be used, after all. I usually use categories when I have a framework and I need to add private methods to a publicly declared class.

Categories on NSObject -- keeping it safe

2 Answers2

Linked