iJoshSmith

Objective-C has a feature called “categories” that allows you to extend the API of a type. It’s somewhat similar to extension methods in C# in that you can define methods which can be invoked on an instance of some class you don’t necessarily have the ability to modify.  For example, you can add methods to NSString or NSArray.  The differences, though, between extension methods and categories are quite revealing.

First off, the methods in a category are treated just like methods defined in the class targeted by the category.  Instance methods in a category reference a ‘self’ pointer (similar to ‘this’ in C#) that points to the object of the target type. They can access private members of the target object.  It looks and feels just like a normal instance method of the target type, only the method is defined in a separate file.  You can also put class (static) methods in a category, which are invoked just like a class method of the target type.

Another thing to know about categories is that they can contain methods that override methods inherited from the target class’s base type(s).  This is a strange concept at first, but it makes more sense once you know that categories are often used to break apart the implementation of large classes.  Unlike extension methods in C#, which are rarely (if ever) used to implement core functionality of a class, categories are a great way to separate logical groups of methods into different source code files.  You cannot add fields to a class from a category, but you can add as many methods as you want.

Now let’s see an example of categories in action.  We’ll start with the demo app’s main function:

The Person class is declared in this header file:

It contains a getter and setter for the ‘name’ field.  It also declares a method called sayHi. Note: Objective-C convention is to not prepend ‘get’ on a getter method if it returns a field, as seen above. Also, a class is allowed to have a method and a field with the same name.  Now let’s look at how the Person class is defined in the .m file:

As you can see, that class does not define the eat: method invoked by main(). That’s where this demo’s category comes into play.  The Consumption category is declared below:

First note that this file’s name is Person+Consumption.h. The naming convention is <class name>+<category name>.ext for files that contain categories.  The @interface is followed by the target type; Person, in this example.  Following that is the name of the category surrounded by parentheses.  The body of the @interface contains declarations of the methods in the category.  Now let’s see how the category is defined:

The category definition contains the eat: method declared previously, which is no surprise.  It also contains an override of the init method inherited from NSObject.  I doubt this is a good practice, but this at least proves it’s possible to override a method from a category.

Here is the result of running the demo program:

To learn more about categories, check out this blog post and the official docs from Apple.

After experimenting with Objective-C for a while now, I find the language is gradually growing on me.  It’s still a bit strange in some spots, and I have a lot left to learn, but it’s starting to make sense.  One of the things I really like about the language is a feature lifted from Smalltalk: using “infix” syntax to send a message.

// invoking a MyCalculator method (by sending it a message)
int sum = [MyCalculator add:29 to:13];

In my previous post I touched on what it means to send a message in Objective-C.  I explained that method calls on a class or object are mediated by a message dispatcher at runtime.  This means that method calls are more involved than just dereferencing a function pointer.  A lookup process occurs, the results of which are cached for subsequent messages.  Objective-C is a superset of traditional C, so you can still call global functions without sending any messages.  Messages only enter the picture when you start dealing with the object-oriented features of the language.

The message being sent above ends up causing a class method to be called on the MyCalculator class.  Objective-C refers to them as “class” methods, not “static” methods like in C#.  The name of the method is add:to: which might take a moment to digest.  As you saw in the code snippet, the method name is broken apart and woven into the argument list.  When you refer to the method, you add all of the pieces together, including the colons.  If the method didn’t take any parameters you would omit the colon altogether.

Here’s the declaration of the MyCalculator class:

#import <Cocoa/Cocoa.h>

@interface MyCalculator : NSObject

+ (int) add:(int) left to:(int) right;

@end

The + sign indicates that add:to: is a class method.  The first (int) means that this method returns an integer.  The rest of the line is the method name, intermixed with the argument list.  I find this style of naming a method to be very intuitive, after getting used to it.  I find myself thinking about naming methods based on the parameters much more carefully and making interesting decisions that I’d never make in C#.

In case you’re interested, here’s the implementation of the MyCalculator class:

#import “MyCalculator.h”

@implementation MyCalculator

+ (int) add:(int) left to:(int) right
{
return left + right;
}

@end

See you next time!

Objective-C is based on good old C.  It also has support for object oriented programming, such as classes, virtual methods, and lots of the goodies I’m accustomed to using in C#. One of the classes included in the Foundation library is NSArray.  It’s basically like a read-only ArrayList in the .NET Framework.

This is an array of strings, Objective-C style:

NSArray * array = [NSArray arrayWithObjects:@"Foo", @"Bar", nil];


For a .NET developer, that line of code might look pretty strange.  Let’s break it apart piece by piece so that it makes more sense.

1. What’s up with that NS prefix on the type name?  It’s a remnant of NeXT Software’s API  from their NeXTStep operating system, which Mac OS X is based on.  You’ll find that Apple framework classes use all-caps prefixes all the time.
2. The * means that the ‘array’ variable is a pointer to an NSArray object.  If you don’t know what a pointer is, I suggest you study up on it before getting into Objective-C much further.  It’s sort of like an object reference in .NET programming, in that it can be used to find an object in memory, but pointers can be used and abused in ways that references cannot (it’s beyond the scope of this post to review pointers).
3. Those [brackets] following the assignment operator indicate that a message is being sent.  Sending a message is similar to, but not the same as, calling a method.  The end result of sending a message to an object, or a class in this case, is that a method will be invoked if the Objective-C message dispatcher can find a suitable method to invoke; otherwise it throws an error.  Also, if you send a message to nil (i.e. a null pointer) it does not crash your app.  It just does nothing and keeps on running.  In other words, method calls are mediated by a message dispatcher at runtime.  This helps the language be very flexible, at the cost of type safety.
4. What’s that ‘arrayWithObjects:‘ all about?  That is the message being sent to the NSArray class.  It causes an immutable array to be created that contains whatever objects are in the parameter listing that follows the colon.
5. Note the @ sign before each string.  That indicates the string is an NSString, instead of a C-style string.
6. Last but not least, the final item in the array is nil.  That is required by NSArray, and other Foundation collection classes.  It basically just puts a zero (0) into the last slot of the array, so that other code can figure out where the array ends.

In case you’re wondering how to loop over the contents of the array, the following loop shows it in action.  It writes each string to the Console window.

for(NSString * s in array)
{
NSLog(@"%@", s);
}

Another point of interest is that the Foundation collection classes won’t let you put primitive C values (like an int or char) into them.  In C# you can add/remove a value type to/from a collection of object references, like ArrayList, because it automatically performs boxing and unboxing for you.  In Objective-C you must do that work yourself.  If you wanted to put, say, an integer into an NSArray, you would box it into an NSNumber object.

If you need to be able to add and remove items, NSArray is not the right collection to use. Instead you need to create an NSMutableArray, which is like an ArrayList in the .NET world.  We’ll explore that class in a future post.

I’m starting to enjoy Objective-C, despite how strange it seems to a hardened C# developer like myself.  I’ll keep you posted with other tidbits and etceteras and such as I keep learning more.  That’s enough for tonight.  Over and out.