posted by Jared White on Wed 7th May 2003 07:13 UTC

"Page 2"

Let's create this MyPerson class right now, which we'll use as an example object for the duration of this article. I'll pretend that objects can do anything in the world, just to make things fun. Say you want to store a few details about a person in a MyPerson object. This object should store information for the person's full name, address, date of birth, and hair color. You also want to be able to send this person a postcard with your name and return address on it along with a message. (I told you objects can do anything!) The interface file (MyPerson.h) might end up looking something like this:

#import <Cocoa/Cocoa.h>

@interface MyPerson : NSObject {
    NSString *fullName;
    NSString *address;
    NSCalendarDate *dateOfBirth;
    NSColor *hairColor;

// Accessor methods
- (void)setFullname:(NSString *)newName;
- (NSString *)fullname;
- (void)setAddress:(NSString *)newAddress;
- (NSString *)address;
- (void)setDateOfBirth:(NSCalendarDate *)newDate;
- (NSCalendarDate *)dateOfBirth;
- (void)setHairColor:(NSColor *)newColor;
- (NSColor *)hairColor;

// Other methods
- (void)sendPostcardWithMessage:(NSString *)message toAddress:(NSString *)address
  fromName:(NSString *)name returnAddress:(NSString *)returnAddress;


Makes sense? No? Well, we'll soon get to the bottom of it. The first line is an import "complier directive". A compiler directive tells the software compiler what to do before processing your code. In this case, it's saying to import the main header file for the Cocoa framework. Cocoa is actually made up of two "kits", the Foundation Kit and the Application Kit, but Cocoa.h imports them both. I'll explain some of the differences between the two kits in a little while.

The next line is where the Objective-C interface starts for your object. The interface declaration is indicated by the @interface bit of code and ends where @end is located (i. e., at the bottom of this file). After @interface we have the name of the class (MyPerson). Then there's a colon followed by the name of the class that MyPerson inherits from. Since MyPerson doesn't require any specific functionality offered by any particular Cocoa class, we're just inheriting from the root object, i. e., NSObject.

Now we've arrived at the spot where your object's instance variables are declared. Right after NSObject is an open curly brace. From here on until the close curly brace, all of the object's instance variables are declared. Now instead of using standard C types such as char (for strings), int, etc., we're opting to use data objects from Cocoa's Foundation Kit. There are many reasons to use Cocoa data objects rather than simple C types, not the least of which is that these objects come built-in with a ton of functionality that will prove to be very useful in any project you build.

So here I'm declaring the instance variables fullName and address to be of the class NSString (which is, of course, Cocoa's default string class for storing text). Now why don't I just declare these variables as being of type id? After all, since Objective-C supports dynamic typing, all objects can always be declared using the id type. Well, while that's true, it's a good idea to "statically type" variables whenever possible because (a) the compiler will warn you if you're trying to send messages to an object that probably aren't supported by that object, and (b) it shows visually (to the programmer) what kind of class the object belongs to.

With that out of the way, we've come to the last two instance variables: dateOfBirth and hairColor. dateOfBirth belongs to the NSCalendarDate class. NSCalendarDate is an object that represents a point in time in the context of the standard western Gregorian calendar. NSCalendarDate is actually a subclass of NSDate, which represents a more low-level interface to time. I've chosen to use NSCalendarDate because that class provides lots of groovy methods that return useful bits of data, such as dayOfMonth or minuteOfHour and the like. The last variable, hairColor, belongs to the class NSColor. NSColor actually is part of Cocoa's Application Kit, because colors aren't usually used outside of the context of a visible application (as opposed to a background process or something like that). NSColor is an object used to represent a color defined in a color space (usually the standard RGB color space of computer screens). The nice thing about NSColor is that it provides a lot of handy class methods such as brownColor, redColor, greenColor, etc., that allocate and initiallize an NSColorobject and hand it back to you with the proper color values already set. Cool, huh? Of course, most people don't have green hair, but they might have a green car or even a green house!

Now we're on to the accessor methods. I mentioned in Part 1 that accessor methods are the preferred way to allow other objects to access or modify your object's instance variables. Here, we have a pair of accessor methods for each variable. So for the fullName variable, we declare two methods: setFullName: and fullName. setFullName: is interesting, because it's the first time I've presented an Objective-C method with an argument. Objective-C differs from some other object-oriented languages in that it uses named arguments. In other words, each variable that you pass on to a method has a name before it. All of these names comprise the full name of a method, also known as the method's signature. This results in the fact that you can have more than one method that starts the same way. For instance, in addition to the setFullName: method declared, we could declare a setFullName:maidenName: method. It might look like this:

- (void)setFullName:(NSString *)newName maidenName:(NSString*)newMaidenName;

Note that the names of the actual variables contained in the method declaration aren't part of the method's signature. In fact, those names could be anything. The line above would mean absolutely the same as this:

- (void)setFullName:(NSString *)abc maidenName:(NSString *)xyz;

OK, so now you know a bit more about methods and their arguments. Most of the time, however, simple accessor method pairs simply feature a "set" method with one argument (the new value, or object, to be assigned to the instance variable), and a "retrieval" method that's simply the name of the instance variable and uses that variable as it's return value. Now this convention of having two accessor methods like that ("setBlahBlahBlah" and "blahBlahBlah") isn't simply around just for kicks and grins. It actually comes in very handy in several cases because some of the more complicated Cocoa design patterns automatically assume that your objects feature accessor methods declared in that manner. So it's usually a very good idea to stick to the convention, unless there's some amazingly overriding reason to do so.

Believe it or not, we're almost done with the interface file! After all of the accessor methods, we have only one "non-standard" method declared: sendPostcardWithMessage:toAddress:fromName:returnAddress:. Whew! That's a pretty long method signature, with four arguments no less! This method allows us to tell a MyPerson object to send a postcard with a certain message to a certain address and specify the name of the person who sent it and also that person's return address. Because of the named arguments, the usage of this method is self-explanatory. It wouldn't be as clear in some other computer languages. So let's say that in another object, you've created a MyPerson object and assigned it to the variable janeDoe. You might send it a message like this:

[janeDoe sendPostcardWithMessage:@"Hi! Wish you were here! Bye!" toAddress:@"1234 Cherry Lane, Bigtown, CA 98765" fromName:@"Joe Smith" returnAddress:@"192 Hotel Drive, Paradiseville, HI 91827"];

Wordy, but very understandable. If you're wondering what all those "@" signs are before the quoted text, that's a special compiler directive that says "create an NSString object containing the following text". It's the easiest way to create Cocoa strings, and you'll find yourself using it almost everywhere all the time.

Table of contents
  1. "Page 1"
  2. "Page 2"
  3. "Page 3"
  4. "Page 4"
  5. "Page 5"
e p (0)    24 Comment(s)

Technology White Papers

See More