In the real world, there are often many objects of the same kind, or type. My iPod is just one of many iPods that exist in the world. In the lingo of object-oriented programming, each iPod is an instance. An instance of an object has its own state and leads an existence independent of all other instances. My iPod probably has a very different collection of music than yours does.^[10] But just as all iPods have the same set of buttons — allowing the same set of operations (play, stop, etc.) — all instances of a particular object expose the same functionality to the outside world.

You specify an object by defining its class. Think of a class as a blueprint for making object instances. It provides all the information needed to build new instances of an object. Each class defines the internal variables that hold the data of an object instance and the ways, or methods , by which that data can be manipulated. These methods define the interface of the object. The interface is how other objects are allowed to use it.

On the back of every iPod is the phrase “Designed by Apple in Cupertino. Assembled in Taiwan.” This is a useful analogy for thinking about how classes and objects relate to each other. In its corporate offices in California, Apple defined how an iPod operates and what kinds of data it can store. Apple shipped those definitions to the factory in Taiwan that now creates many unique instances of an iPod to ship to customers around the world. When you create a class, you create a definition from which the runtime (the layer of software that enables the object-oriented system to run) can create any number of objects (see Figure 3-2).

Figure 3-2. Runtime creates object instances from a class

In Objective-C, classes are more than just blueprints. They are actually first-class objects themselves that can have methods associated with the class and not with its instances. These are called class methods . Every object created has a reference to its own class. The iPod analogy starts to get a bit stretched here, but imagine that each iPod had a reference to the plans on which it was based and could consult them at any time. This is sort of what it means for an object to look up its class object anytime it needs to do so.

We’ve defined a class to be a definition, or blueprint, from which object-oriented instances are created. An iPod is an instance of the iPod class. But classes themselves can be defined as specializations of other classes. For example, if you didn’t know what an iPod was, you would probably understand if I told you that it was a handheld MP3 player. In fact, all handheld MP3 players share a certain number of characteristics. Like an iPod, a Rio can hold and play MP3 files downloaded from a computer. It can’t hold as many songs as the iPod, but at least some of the functionality is the same.

Object-oriented programming lets us collect similar functionalities of different classes and group them into a common parent class through inheritance. We can say that an iPod and a Rio are both types of MP3 players. If we define a common MP3Player class, we can gather certain aspects common to both devices into one class, as shown in Figure 3-3.

The iPod and Rio classes are both subclasses of the MP3Player class. Likewise, the MP3Player class is the superclass of the iPod and Rio classes. Each subclass inherits state (in the form of variable definitions) and functionality from the superclass. In this case, both players inherit the same basic functions (play, stop, fast forward, etc.), but have very different underlying implementations. The iPod uses a high-capacity hard drive while the Rio uses flash memory.

Figure 3-3. Class hierarchy for the MP3Player class

Creating a new class is often a matter of specialization. Since the new class inherits all of its superclass’s behavior, you don’t need to reimplement the things that work in the way that you want. The subclass merely extends the inherited behavior by adding new methods and any variables needed to support the additional methods. A subclass can alter superclass behavior by overriding an inherited method, reimplementing the method to achieve a behavior different from the superclass’s implementation.

With Objective-C, a class can have any number of subclasses, but only one superclass.^[11] This means that classes are arranged in a branching hierarchy with one class at the top—the root class that has no superclass—as shown in Figure 3-4.

Figure 3-4. The root class in Objective-C

NSObject is the root class of this hierarchy. From NSObject, other classes inherit the basic functionality that lets them work in the system. The root class also creates a framework for the creation, initialization, deallocation, introspection, and storage of objects.

As noted earlier, you often create a subclass of another class because that superclass provides most, but not all, of the behavior that you require. A subclass can have its own unique purpose that does not build on the role of an existing class. To define a new class that doesn’t need to inherit any special behavior other than the default behavior of objects, you make it a subclass of NSObject.

Working with multiple object instances of the same class is easy, as long as you keep the references to different objects distinct.

The message in Figure 3-5 calls a method that doesn’t take any arguments. Like procedures, methods can receive multiple arguments. In Objective-C, every message argument is identified with a label (a colon-terminated keyword), which is considered part of the method name. Figure 3-6 shows a message with a single argument.

Figure 3-6. Objective-C message expression with a single argument

In this figure, the message tells the runtime to call the setWidth: method and pass it the argument width. Notice that a colon terminates method names that take an argument, while method names that don’t take an argument (like the alloc method in Figure 3-5) don’t have a colon.

Figure 3-7 shows a multiple-argument message. Here, the message and arguments are used to set the width and height of the rectangle object to width and height, respectively. This method is called the setWidth:height: method.

Figure 3-7. Objective-C message expression with multiple arguments

Figure 3-8 shows nested messages. By enclosing one message within another, you can use a returned value as an argument without having to declare a variable for it. The innermost message expression is evaluated first, resulting in a return object. Then the next nested message expression is evaluated using the object that was returned in the inner expression as the receiver of the second message. We saw this in action in Example 3-2 when we combined the alloc and init methods of NSObject.

Figure 3-8. Nested Objective-C messages

The NSObject class ensures that every object in the system has an instance variable named isa . This variable points to the class that defines how the object works.In addition, every class object has a reference to its superclass. This relationship is illustrated in Figure 3-9.

Figure 3-9. Instances have a reference to their class.

The class object contains quite a bit of information about the internals of the class and how it works. Part of this information is a method lookup table that maps selectors to methods, as shown in Figure 3-10.

Figure 3-10. Method lookup table

A selector (defined as the SEL type in Objective-C) is a compiler-assigned code that identifies a method to the runtime. When you send a message to an object, the compiler actually creates code to perform a call to an Objective-C-defined function, which uses the selector information to perform a dynamic method lookup at runtime. For more details about how this functionality works underneath the hood, read Inside Mac OS X: The Objective-C Language, located in the /Developer/Documentation /Cocoa/ObjectiveC folder.

Edit the Song.h file as shown in Example 3-4. Once again, the lines that you need to add are shown in boldface type.

@interface Song : NSObject {
    NSString * name;                                                           // a
    NSString * artist;                                                         // b
}
- (NSString *)name;                                                            // c
- (void)setName:(NSString *)newName;                                           // d
- (NSString *)artist;                                                          // e
- (void)setArtist:(NSString *)newArtist;                                       // f
@end

Here’s what the additional code does:

Now that we have defined the interface, we actually need to fill in the implementation of the class. Take a look at the Song.m file. You will notice that it imports Song.h, which is the application’s interface. There are also two compiler directives, @implementation Song and @end.

Add the code shown in Example 3-5 between the @implementation and @end directives.

#import "Song.h"

@implementation Song

- (NSString *)name                              // a
{ 
    return name;                                                      // b
} 

- (void)setName:(NSString *)newName                                   // c
{
     [newName retain];                                                // d
    [name release];                                                   // e
    name = newName;                                                   // f
}

- (NSString *)artist                                                  // g
{
    return artist;                                                    // h
}

- (void)setArtist:(NSString *)newArtist                               // i
{
    [newArtist retain];                                               // j
    [artist release];                                                 // k
    artist = newArtist;                                               // l
}



@end

Here’s what the additional code does:

Now, we need to edit the main function in the main.m file, so we can do something with the Song class.

You will recognize that this output is similar to the output that was printed from the NSObject object instances. This is because the NSLog method actually calls the description method on an object, as defined by the NSObject class. To change this to print something a bit more user-friendly, we somehow need to redefine what the description method prints .

Sometimes, in a method that overrides a superclass’s method, calling the functionality in the superclass’s method can be useful. To do this, you can send a message to super, a special variable in the Objective-C language. When you send a message to super, it indicates that an inherited method should be performed, rather than the method in the current class.

For example, if we wanted to print the same information that the NSObject class prints in the description method, we could implement our description method as follows:

- (NSString *)description
{
    return [super description];
}

If we were to make this change, we would see the following output:

2002-06-11 22:37:03.997 Songs[7115] Song 1: <Song: 0x53100>
2002-06-11 22:37:03.998 Songs[7115] Song 2: <Song: 0x530a0>

Since this defeats the purpose of overriding the description method, we’re not going to add this implementation to our Song class. If you experiment with this, be sure to set it back to return [self description].

One of a class’s primary functions is to create new objects of the type defined by the class. As we’ve seen, objects are created at runtime in a two-step process that first allocates memory for the instance variables of the new object and then initializes those variables. We’ve said this before, but because it’s important, we’ll repeat it here: an alloc message should always be coupled with an init message in the same line of code. The receiver for the alloc message is a class, while the receiver for the init message is the new object instance:

TheClass * newObject = [[TheClass alloc] init];

The alloc method dynamically allocates memory for a new instance of the receiving class and returns the new object. The receiver for the init message is the new object that was dynamically allocated by alloc. An object isn’t ready for use until it is initialized, but it should be initialized only once. The version of the init method defined in the NSObject class does very little. In fact, it simply returns self, a special variable in Objective-C that is defined to point to the object that is called upon by the method.

After being allocated and initialized, a new object is a fully functional member of its class with its own set of variables. The newObject object can receive messages, store values in its instance variables, and so on.

Subclass versions of the init method should return the new object (self) after it has been successfully initialized. If it can’t be initialized, the method should release the object and return nil. In some cases, an init method might release the new object and return a substitute. Programs should therefore always use the object returned by init, and not necessarily the one returned by alloc.

Subclass versions of init incorporate the initialization code for the classes from which they inherit through a message to super. When working with classes that inherit from NSObject, a simple call to the superclass init method, as shown in the following code block, is sufficient.

- init
{
    [super init];
    /* class-specific initialization goes here */
    return self;
}

Note that the message to super precedes the initialization code added in the method. This ensures that initialization proceeds in the order of inheritance.

However, since extending classes other than NSObject may return a different object than that on which the initializer was called, you must be more careful in these cases and use the following code:

- init
{
    if (self = [super init]) {
        /* class specific initialization goes here */
    }
    return self;
}

Note that this code checks to see if super returned an object, or nil, before doing any initialization itself. This code will work in any situation; however, none of the classes that we create in this book require these checks.

- (id)initWithName:(NSString *)newName artist:(NSString *)newArtist;

We have a flaw in our very simple program in the form of a memory leak. Of course, this leak is probably not going to hurt anybody — since the program exits so quickly, allowing the operating system to reclaim all the memory belonging to the process — but it doesn’t pay to get into bad habits. As well, code has a tendency to be reused in ways that the original author did not expect. Therefore, you should always make a point of cleaning up after your code, no matter how simple it is.

When an object is no longer being used by the program, it must be deallocated. When an object is released, the dealloc method (provided by the NSObject class) is called, letting it release objects it has created, free allocated memory, and so on. Since our Song class has two instance variable objects, they need to be released when an instance of the class is released.

In Chapter 4, we present the finer details of memory management and explain why the act of releasing an object here calls the dealloc method of our Song objects.