Is using C functions instead of static methods for making pure functions a bad design?

Question

If I am implementing a function that does some calculation based on certain input and returns the output without causing any side effects.

I always use Regular C functions instead of having static methods in a class.

Is there a rationale behind using static methods forcefully put into a class ?

I am not talking about methods that create singletons or factory methods but the regular methods like there:

Instead of having something like this:

+(NSString *)generateStringFromPrefixString:(NSString *)prefixString word:(NSString *)word;

won't this be better ?

NSString *generateString(NSString *prefixString, NSString *word);

In terms of efficiency also, wont we be saving, lookup for the selector to get the function pointer ?

Answer 1

Objective-C doesn't have such a thing as "static methods". It has class methods. This isn't just picking a nit because class methods are dispatched dynamically, not statically. And that can be one reason to use a class method rather than a function: it allows for subclasses to override it.

By contrast, that can also be a reason to use a function rather than a class method – to prevent it from being overridden.

But, in general, there's no rule that you have to use class methods. If a function suits your needs and your preferences, use a function.

Answer 2

I don't think it is bad design, no, but there are certain circumstances where one may be considered more appropriate than the other. The key questions are:

• Does this method belong to a class?
• Is this method worth adding to a class?

A class is something that is self-contained and reusable. For the method in your example, I would be tempted to answer "Yes, it does/is," because it is something specific to NSString and is a method you (presumably) want to use fairly often. Its parameters are also of type NSString. I would therefore use the message form in a class extension and #import the extension when you need it.

There are two situations (off the top of my head) where this is not really appropriate. Firstly is the situation where the method interacts specifically with other entities outside of the 'main class'. Examples of this can be found near the bottom of Apple's NSObjcRuntime.h file. These are all standard C functions. They don't really belong to a specific class.

The second situation to use a standard C function is when it will only be used once (or very few times) in a very specific circumstance. UIApplicationMain is the perfect example, and helper methods for a specific UIView subclass's -drawRect: method also come to mind.

A final point on efficiency. Yes, selector lookup is fractionally slower standard C calls. However, the runtime (Apple's at least, can't comment on GCC's) does use a caching system so that the most commonly sent messages quickly gravitate to the 'top' of the selector table.

Disclaimer: This is somewhat a question of a style and the above recommendations are the way I would do it as I think it makes code more organised and readable. I'm sure there are other equally valid ways to structure/interleave C and Objective-C code.