Objects and Classes

Objects

As the name implies, object-oriented programs are built around objects. An object associates data with the particular operations that can use or affect that data. In Objective-C, these operations are known as the object’s methods; the data they affect are its instance variables. In essence, an object bundles a data structure (instance variables) and a group of procedures (methods) into a self-contained programming unit.

For example, if you are writing a drawing program that allows a user to create images composed of lines, circles, rectangles, text, bit-mapped images, and so forth, you might create classes for many of the basic shapes that a user can manipulate. A Rectangle object, for instance, might have instance variables that identify the position of the rectangle within the drawing along with its width and its height. Other instance variables could define the rectangle’s color, whether or not it is to be filled, and a line pattern that should be used to display the rectangle. A Rectangle class would have methods to set an instance’s position, size, color, fill status, and line pattern, along with a method that causes the instance to display itself.

In Objective-C, an object’s instance variables are internal to the object; generally, you get access to an object’s state only through the object’s methods (you can specify whether subclasses or other objects can access instance variables directly by using scope directives, see “The Scope of Instance Variables”). For others to find out something about an object, there has to be a method to supply the information. For example, a Rectangle would have methods that reveal its size and its position.

Moreover, an object sees only the methods that were designed for it; it can’t mistakenly perform methods intended for other types of objects. Just as a C function protects its local variables, hiding them from the rest of the program, an object hides both its instance variables and its method implementations.

In this section:

id
Dynamic Typing

id

In Objective-C, object identifiers are a distinct data type: id. This type is defined as a pointer to an object—in reality, a pointer to the instance variables of the object, the object’s unique data. Like a C function or an array, an object is identified by its address. All objects, regardless of their instance variables or methods, are of type id.

id anObject;

For the object-oriented constructs of Objective-C, such as method return values, id replaces int as the default data type. (For strictly C constructs, such as function return values, int remains the default type.)

The keyword nil is defined as a null object, an id with a value of 0. id, nil, and the other basic types of Objective-C are defined in the header file objc/objc.h.

Dynamic Typing

The id type is completely nonrestrictive. By itself, it yields no information about an object, except that it is an object.

But objects aren’t all the same. A Rectangle won’t have the same methods or instance variables as an object that represents a bit-mapped image. At some point, a program needs to find more specific information about the objects it contains—what the object’s instance variables are, what methods it can perform, and so on. Since the id type designator can’t supply this information to the compiler, each object has to be able to supply it at runtime.

This is possible because every object carries with it an isa instance variable that identifies the object’s class—what kind of object it is. Every Rectangle object would be able to tell the runtime system that it is a Rectangle. Every Circle can say that it is a Circle. Objects with the same behavior (methods) and the same kinds of data (instance variables) are members of the same class.

Objects are thus dynamically typed at runtime. Whenever it needs to, the runtime system can find the exact class that an object belongs to, just by asking the object. Dynamic typing in Objective-C serves as the foundation for dynamic binding, discussed later.

The isa pointer also enables objects to perform introspection—to find out about themselves (or other objects). The compiler records information about class definitions in data structures for the runtime system to use. The functions of the runtime system use isa, to find this information at runtime. Using the runtime system, you can, for example, determine whether an object implements a particular method, or discover the name of its superclass.

Object classes are discussed in more detail under “Classes.”

It’s also possible to give the compiler information about the class of an object by statically typing it in source code using the class name. Classes are particular kinds of objects, and the class name can serve as a type name. See “Class Types” and “Enabling Static Behavior.”

Object Messaging

This section explains the syntax of sending messages, including how you can nest message expressions. It also discusses the “visibility” of an object’s instance variables, and the concepts of polymorphism and dynamic binding.

In this section:

Message Syntax
Sending Messages to nil
The Receiver’s Instance Variables
Polymorphism
Dynamic Binding

Message Syntax

To get an object to do something, you send it a message telling it to apply a method. In Objective-C, message expressions are enclosed in brackets:

[receiver message]

The receiver is an object, and the message tells it what to do. In source code, the message is simply the name of a method and any arguments that are passed to it. When a message is sent, the runtime system selects the appropriate method from the receiver’s repertoire and invokes it.

For example, this message tells the myRect object to perform its display method, which causes the rectangle to display itself:

[myRect display];

Methods can also take arguments. The imaginary message below tells myRect to set its location within the window to coordinates (30.0, 50.0):

[myRect setOrigin:30.0 :50.0];

Here the method name, setOrigin::, has two colons, one for each of its arguments. The arguments are inserted after the colons. This method name uses unlabeled arguments. Unlabeled arguments make it difficult to determine the kind and purpose of a method’s arguments. Instead, method names should include labels describing each of their arguments. Argument labels precede each colon in the method name. The setWidth:height: method, for example, makes the purpose of its two arguments clear:

[myRect setWidth:10.0 height:15.0];

Methods that take a variable number of arguments are also possible, though they’re somewhat rare. Extra arguments are separated by commas after the end of the method name. (Unlike colons, the commas aren’t considered part of the name.) In the following example, the imaginary makeGroup: method is passed one required argument (group) and three that are optional:

[receiver makeGroup:group, memberOne, memberTwo, memberThree];

Like standard C functions, methods can return values. The following example sets the variable isFilled to YES if myRect is drawn as a solid rectangle, or NO if it’s drawn in outline form only.

BOOL isFilled;

isFilled = [myRect isFilled];

Note that a variable and a method can have the same name.

One message expression can be nested inside another. Here, the color of one rectangle is set to the color of another:

[myRect setPrimaryColor:[otherRect primaryColor]];

Sending Messages to nil

In Objective-C, it is valid to send a message to nil—it simply has no effect at runtime. There are several patterns in Cocoa that take advantage of this fact. The value returned from a message to nil may also be valid:

• If the method returns an object, any pointer type, any integer scalar of size less than or equal to sizeof(void*), a float, a double, a long double, or a long long, then a message sent to nil returns 0.

• If the method returns a struct, as defined by the Mac OS X ABI Function Call Guide to be returned in registers, then a message sent to nil returns 0.0 for every field in the data structure. Other struct data types will not be filled with zeros.

• If the method returns anything other than the aforementioned value types the return value of a message sent to nil is undefined.

The following code fragment illustrates valid use of sending a message to nil.

id anObjectMaybeNil = nil;

// this is valid

if ([anObjectMaybeNil methodThatReturnsADouble] == 0.0)

{

    // implementation continues...

}

The Receiver’s Instance Variables

A method has automatic access to the receiving object’s instance variables. You don’t need to pass them to the method as arguments. For example, the primaryColor method illustrated above takes no arguments, yet it can find the primary color for otherRect and return it. Every method assumes the receiver and its instance variables, without having to declare them as arguments.

This convention simplifies Objective-C source code. It also supports the way object-oriented programmers think about objects and messages. Messages are sent to receivers much as letters are delivered to your home. Message arguments bring information from the outside to the receiver; they don’t need to bring the receiver to itself.

A method has automatic access only to the receiver’s instance variables. If it requires information about a variable stored in another object, it must send a message to the object asking it to reveal the contents of the variable. The primaryColor and isFilled methods shown above are used for just this purpose.

See “Defining a Class” for more information on referring to instance variables.

Polymorphism

As the examples above illustrate, messages in Objective-C appear in the same syntactic positions as function calls in standard C. But, because methods “belong to” an object, messages behave differently than function calls.

In particular, an object can be operated on by only those methods that were defined for it. It can’t confuse them with methods defined for other kinds of objects, even if another object has a method with the same name. This means that two objects can respond differently to the same message. For example, each kind of object sent a display message could display itself in a unique way. A Circle and a Rectangle would respond differently to identical instructions to track the cursor.

This feature, referred to as polymorphism, plays a significant role in the design of object-oriented programs. Together with dynamic binding, it permits you to write code that might apply to any number of different kinds of objects, without you having to choose at the time you write the code what kinds of objects they might be. They might even be objects that will be developed later, by other programmers working on other projects. If you write code that sends a display message to an id variable, any object that has a display method is a potential receiver.

Dynamic Binding

A crucial difference between function calls and messages is that a function and its arguments are joined together in the compiled code, but a message and a receiving object aren’t united until the program is running and the message is sent. Therefore, the exact method that’s invoked to respond to a message can only be determined at runtime, not when the code is compiled.

The precise method that a message invokes depends on the receiver. Different receivers may have different method implementations for the same method name (polymorphism). For the compiler to find the right method implementation for a message, it would have to know what kind of object the receiver is—what class it belongs to. This is information the receiver is able to reveal at runtime when it receives a message (dynamic typing), but it’s not available from the type declarations found in source code.

The selection of a method implementation happens at runtime. When a message is sent, a runtime messaging routine looks at the receiver and at the method named in the message. It locates the receiver’s implementation of a method matching the name, “calls” the method, and passes it a pointer to the receiver’s instance variables. (For more on this routine, see “How Messaging Works.”)

The method name in a message thus serves to “select” a method implementation. For this reason, method names in messages are often referred to as selectors.

This dynamic binding of methods to messages works hand-in-hand with polymorphism to give object-oriented programming much of its flexibility and power. Since each object can have its own version of a method, a program can achieve a variety of results, not by varying the message itself, but by varying just the object that receives the message. This can be done as the program runs; receivers can be decided “on the fly” and can be made dependent on external factors such as user actions.

When executing code based upon the Application Kit, for example, users determine which objects receive messages from menu commands like Cut, Copy, and Paste. The message goes to whatever object controls the current selection. An object that displays text would react to a copy message differently from an object that displays scanned images. An object that represents a set of shapes would respond differently from a Rectangle. Since messages don’t select methods (methods aren’t bound to messages) until runtime, these differences are isolated in the methods that respond to the message. The code that sends the message doesn’t have to be concerned with them; it doesn’t even have to enumerate the possibilities. Each application can invent its own objects that respond in their own way to copy messages.

Objective-C takes dynamic binding one step further and allows even the message that’s sent (the method selector) to be a variable that’s determined at runtime. This is discussed in the section “How Messaging Works.”

Classes

An object-oriented program is typically built from a variety of objects. A program based on the Cocoa frameworks might use NSMatrix objects, NSWindow objects, NSDictionary objects, NSFont objects, NSText objects, and many others. Programs often use more than one object of the same kind or class—several NSArray objects or NSWindow objects, for example.

In Objective-C, you define objects by defining their class. The class definition is a prototype for a kind of object; it declares the instance variables that become part of every member of the class, and it defines a set of methods that all objects in the class can use.

The compiler creates just one accessible object for each class, a class object that knows how to build new objects belonging to the class. (For this reason it’s traditionally called a “factory object.”) The class object is the compiled version of the class; the objects it builds are instances of the class. The objects that do the main work of your program are instances created by the class object at runtime.

All instances of a class have the same set of methods, and they all have a set of instance variables cut from the same mold. Each object gets its own instance variables, but the methods are shared.

By convention, class names begin with an uppercase letter (such as “Rectangle”); the names of instances typically begin with a lowercase letter (such as “myRect”).

In this section:

Inheritance
Class Types
Class Objects
Class Names in Source Code

Inheritance

Class definitions are additive; each new class that you define is based on another class from which it inherits methods and instance variables. The new class simply adds to or modifies what it inherits. It doesn’t need to duplicate inherited code.

Inheritance links all classes together in a hierarchical tree with a single class at its root. When writing code that is based upon the Foundation framework, that root class is typically NSObject. Every class (except a root class) has a superclass one step nearer the root, and any class (including a root class) can be the superclass for any number of subclasses one step farther from the root. Figure 1-1 illustrates the hierarchy for a few of the classes used in the drawing program.

Figure 1-1  Some Drawing Program Classes

This figure shows that the Square class is a subclass of the Rectangle class, the Rectangle class is a subclass of Shape, Shape is a subclass of Graphic, and Graphic is a subclass of NSObject. Inheritance is cumulative. So a Square object has the methods and instance variables defined for Rectangle, Shape, Graphic, and NSObject, as well as those defined specifically for Square. This is simply to say that a Square object isn’t only a Square, it’s also a Rectangle, a Shape, a Graphic, and an NSObject.

Every class but NSObject can thus be seen as a specialization or an adaptation of another class. Each successive subclass further modifies the cumulative total of what’s inherited. The Square class defines only the minimum needed to turn a Rectangle into a Square.

When you define a class, you link it to the hierarchy by declaring its superclass; every class you create must be the subclass of another class (unless you define a new root class). Plenty of potential superclasses are available. Cocoa includes the NSObject class and several frameworks containing definitions for more than 250 additional classes. Some are classes that you can use “off the shelf”—incorporate into your program as is. Others you might want to adapt to your own needs by defining a subclass.

Some framework classes define almost everything you need, but leave some specifics to be implemented in a subclass. You can thus create very sophisticated objects by writing only a small amount of code, and reusing work done by the programmers of the framework.

The NSObject Class

NSObject is a root class, and so doesn’t have a superclass. It defines the basic framework for Objective-C objects and object interactions. It imparts to the classes and instances of classes that inherit from it the ability to behave as objects and cooperate with the runtime system.

A class that doesn’t need to inherit any special behavior from another class should nevertheless be made a subclass of the NSObject class. Instances of the class must at least have the ability to behave like Objective-C objects at runtime. Inheriting this ability from the NSObject class is much simpler and much more reliable than reinventing it in a new class definition.

Inheriting Instance Variables

When a class object creates a new instance, the new object contains not only the instance variables that were defined for its class but also the instance variables defined for its superclass and for its superclass’s superclass, all the way back to the root class. Thus, the isa instance variable defined in the NSObject class becomes part of every object. isa connects each object to its class.

Figure 1-2 shows some of the instance variables that could be defined for a particular implementation of Rectangle, and where they may come from. Note that the variables that make the object a Rectangle are added to the ones that make it a Shape, and the ones that make it a Shape are added to the ones that make it a Graphic, and so on.

Figure 1-2  Rectangle Instance Variables

A class doesn’t have to declare instance variables. It can simply define new methods and rely on the instance variables it inherits, if it needs any instance variables at all. For example, Square might not declare any new instance variables of its own.

Inheriting Methods

An object has access not only to the methods defined for its class, but also to methods defined for its superclass, and for its superclass’s superclass, all the way back to the root of the hierarchy. For instance, a Square object can use methods defined in the Rectangle, Shape, Graphic, and NSObject classes as well as methods defined in its own class.

Any new class you define in your program can therefore make use of the code written for all the classes above it in the hierarchy. This type of inheritance is a major benefit of object-oriented programming. When you use one of the object-oriented frameworks provided by Cocoa, your programs can take advantage of the basic functionality coded into the framework classes. You have to add only the code that customizes the standard functionality to your application.

Class objects also inherit from the classes above them in the hierarchy. But because they don’t have instance variables (only instances do), they inherit only methods.

Overriding One Method With Another

There’s one useful exception to inheritance: When you define a new class, you can implement a new method with the same name as one defined in a class farther up the hierarchy. The new method overrides the original; instances of the new class perform it rather than the original, and subclasses of the new class inherit it rather than the original.

For example, Graphic defines a display method that Rectangle overrides by defining its own version of display. The Graphic method is available to all kinds of objects that inherit from the Graphic class—but not to Rectangle objects, which instead perform the Rectangle version of display.

Although overriding a method blocks the original version from being inherited, other methods defined in the new class can skip over the redefined method and find the original (see “Messages to self and super” to learn how).

A redefined method can also incorporate the very method it overrides. When it does, the new method serves only to refine or modify the method it overrides, rather than replace it outright. When several classes in the hierarchy define the same method, but each new version incorporates the version it overrides, the implementation of the method is effectively spread over all the classes.

Although a subclass can override inherited methods, it can’t override inherited instance variables. Since an object has memory allocated for every instance variable it inherits, you can’t override an inherited variable by declaring a new one with the same name. If you try, the compiler will complain.

Abstract Classes

Some classes are designed only or primarily so that other classes can inherit from them. These abstract classes group methods and instance variables that can be used by a number of different subclasses into a common definition. The abstract class is typically incomplete by itself, but contains useful code that reduces the implementation burden of its subclasses.

The NSObject class is the prime example of an abstract class. Although programs often define NSObject subclasses and use instances belonging to the subclasses, they never use instances belonging directly to the NSObject class. An NSObject instance wouldn’t be good for anything; it would be a generic object with the ability to do nothing in particular.

The NSView class provides an example of an abstract class that may be used directly.

Abstract classes often contain code that helps define the structure of an application. When you create subclasses of these classes, instances of your new classes fit effortlessly into the application structure and work automatically with other objects.

(Because abstract classes must have subclasses to be useful, they’re sometimes also called abstract superclasses.)

Class Types

A class definition is a specification for a kind of object. The class, in effect, defines a data type. The type is based not just on the data structure the class defines (instance variables), but also on the behavior included in the definition (methods).

A class name can appear in source code wherever a type specifier is permitted in C—for example, as an argument to the sizeof operator:

int i = sizeof(Rectangle);

Static Typing

You can use a class name in place of id to designate an object’s type:

Rectangle *myRect;

Because this way of declaring an object type gives the compiler information about the kind of object it is, it’s known as static typing. Just as id is defined as a pointer to an object, objects are statically typed as pointers to a class. Objects are always typed by a pointer. Static typing makes the pointer explicit; id hides it.

Static typing permits the compiler to do some type checking—for example, to warn if an object could receive a message that it appears not to be able to respond to—and to loosen some restrictions that apply to objects generically typed id. In addition, it can make your intentions clearer to others who read your source code. However, it doesn’t defeat dynamic binding or alter the dynamic determination of a receiver’s class at runtime.

An object can be statically typed to its own class or to any class that it inherits from. For example, since inheritance makes a Rectangle a kind of Graphic, a Rectangle instance could be statically typed to the Graphic class:

Graphic *myRect;

This is possible because a Rectangle is a Graphic. It’s more than a Graphic since it also has the instance variables and method capabilities of a Shape and a Rectangle, but it’s a Graphic nonetheless. For purposes of type checking, the compiler considers myRect to be a Graphic, but at runtime it’s treated as a Rectangle.

See “Enabling Static Behavior” for more on static typing and its benefits.

Type Introspection

Instances can reveal their types at runtime. The isMemberOfClass: method, defined in the NSObject class, checks whether the receiver is an instance of a particular class:

if ( [anObject isMemberOfClass:someClass] )

    ...

The isKindOfClass: method, also defined in the NSObject class, checks more generally whether the receiver inherits from or is a member of a particular class (whether it has the class in its inheritance path):

if ( [anObject isKindOfClass:someClass] )

    ...

The set of classes for which isKindOfClass: returns YES is the same set to which the receiver can be statically typed.

Introspection isn’t limited to type information. Later sections of this chapter discuss methods that return the class object, report whether an object can respond to a message, and reveal other information.

See the NSObject class specification in the Foundation framework reference for more on isKindOfClass:, isMemberOfClass:, and related methods.

Class Objects

A class definition contains various kinds of information, much of it about instances of the class:

• The name of the class and its superclass

• A template describing a set of instance variables

• The declarations of method names and their return and argument types

• The method implementations

This information is compiled and recorded in data structures made available to the runtime system. The compiler creates just one object, a class object, to represent the class. The class object has access to all the information about the class, which means mainly information about what instances of the class are like. It’s able to produce new instances according to the plan put forward in the class definition.

Although a class object keeps the prototype of a class instance, it’s not an instance itself. It has no instance variables of its own and it can’t perform methods intended for instances of the class. However, a class definition can include methods intended specifically for the class object—class methods as opposed to instance methods. A class object inherits class methods from the classes above it in the hierarchy, just as instances inherit instance methods.

In source code, the class object is represented by the class name. In the following example, the Rectangle class returns the class version number using a method inherited from the NSObject class:

int versionNumber = [Rectangle version];

However, the class name stands for the class object only as the receiver in a message expression. Elsewhere, you need to ask an instance or the class to return the class id. Both respond to a class message:

id aClass = [anObject class];

id rectClass = [Rectangle class];

As these examples show, class objects can, like all other objects, be typed id. But class objects can also be more specifically typed to the Class data type:

Class aClass = [anObject class];

Class rectClass = [Rectangle class];

All class objects are of type Class. Using this type name for a class is equivalent to using the class name to statically type an instance.

Class objects are thus full-fledged objects that can be dynamically typed, receive messages, and inherit methods from other classes. They’re special only in that they’re created by the compiler, lack data structures (instance variables) of their own other than those built from the class definition, and are the agents for producing instances at runtime.

Creating Instances

A principal function of a class object is to create new instances. This code tells the Rectangle class to create a new Rectangle instance and assign it to the myRect variable:

id  myRect;

myRect = [Rectangle alloc];

The alloc method dynamically allocates memory for the new object’s instance variables and initializes them all to 0—all, that is, except the isa variable that connects the new instance to its class. For an object to be useful, it generally needs to be more completely initialized. That’s the function of an init method. Initialization typically follows immediately after allocation:

myRect = [[Rectangle alloc] init];

This line of code, or one like it, would be necessary before myRect could receive any of the messages that were illustrated in previous examples in this chapter. The alloc method returns a new instance and that instance performs an init method to set its initial state. Every class object has at least one method (like alloc) that enables it to produce new objects, and every instance has at least one method (like init) that prepares it for use. Initialization methods often take arguments to allow particular values to be passed and have keywords to label the arguments (initWithPosition:size:, for example, is a method that might initialize a new Rectangle instance), but they all begin with “init”.

Customization With Class Objects

It’s not just a whim of the Objective-C language that classes are treated as objects. It’s a choice that has intended, and sometimes surprising, benefits for design. It’s possible, for example, to customize an object with a class, where the class belongs to an open-ended set. In the Application Kit, for example, an NSMatrix object can be customized with a particular kind of NSCell object.

An NSMatrix object can take responsibility for creating the individual objects that represent its cells. It can do this when the matrix is first initialized and later when new cells are needed. The visible matrix that an NSMatrix object draws on the screen can grow and shrink at runtime, perhaps in response to user actions. When it grows, the matrix needs to be able to produce new objects to fill the new slots that are added.

But what kind of objects should they be? Each matrix displays just one kind of NSCell, but there are many different kinds. The inheritance hierarchy in Figure 1-3 shows some of those provided by the Application Kit. All inherit from the generic NSCell class:

Figure 1-3  Inheritance hierarchy for NSCell

When a matrix creates NSCell objects, should they be NSButtonCell objects to display a bank of buttons or switches, NSTextFieldCell objects to display fields where the user can enter and edit text, or some other kind of NSCell? The NSMatrix object must allow for any kind of cell, even types that haven’t been invented yet.

One solution to this problem is to define the NSMatrix class as an abstract class and require everyone who uses it to declare a subclass and implement the methods that produce new cells. Because they would be implementing the methods, users of the class could be sure that the objects they created were of the right type.

But this requires others to do work that ought to be done in the NSMatrix class, and it unnecessarily proliferates the number of classes. Since an application might need more than one kind of NSMatrix, each with a different kind of NSCell, it could become cluttered with NSMatrix subclasses. Every time you invented a new kind of NSCell, you’d also have to define a new kind of NSMatrix. Moreover, programmers on different projects would be writing virtually identical code to do the same job, all to make up for NSMatrix´s failure to do it.

A better solution, the solution the NSMatrix class actually adopts, is to allow NSMatrix instances to be initialized with a kind of NSCell—with a class object. It defines a setCellClass: method that passes the class object for the kind of NSCell object an NSMatrix should use to fill empty slots:

[myMatrix setCellClass:[NSButtonCell class]];

The NSMatrix object uses the class object to produce new cells when it’s first initialized and whenever it’s resized to contain more cells. This kind of customization would be difficult if classes weren’t objects that could be passed in messages and assigned to variables.

Variables and Class Objects

When you define a new class, you can specify instance variables. Every instance of the class can maintain its own copy of the variables you declare—each object controls its own data. There is, however, no “class variable” counterpart to an instance variable. Only internal data structures, initialized from the class definition, are provided for the class. Moreover, a class object has no access to the instance variables of any instances; it can’t initialize, read, or alter them.

For all the instances of a class to share data, you must define an external variable of some sort. The simplest way to do this is to declare a variable in the class implementation file as illustrated in the following code fragment.

int MCLSGlobalVariable;

@implementation MyClass

// implementation continues

In a more sophisticated implementation, you can declare a variable to be static, and provide class methods to manage it. Declaring a variable static limits its scope to just the class—and to just the part of the class that’s implemented in the file. (Thus unlike instance variables, static variables cannot be inherited by, or directly manipulated by, subclasses.) This pattern is commonly used to define shared instances of a class (such as singletons, see Creating a Singleton Instance).

static MyClass *MCLSSharedInstance;

@implementation MyClass

+ (MyClass *)sharedInstance

{

    // check for existence of shared instance

    // create if necessary

    return MCLSSharedInstance;

}

// implementation continues

Static variables help give the class object more functionality than just that of a “factory” producing instances; it can approach being a complete and versatile object in its own right. A class object can be used to coordinate the instances it creates, dispense instances from lists of objects already created, or manage other processes essential to the application. In the case when you need only one object of a particular class, you can put all the object’s state into static variables and use only class methods. This saves the step of allocating and initializing an instance.

Initializing a Class Object

If a class object is to be used for anything besides allocating instances, it may need to be initialized just as an instance is. Although programs don’t allocate class objects, Objective-C does provide a way for programs to initialize them.

If a class makes use of static or global variables, the initialize method is a good place to set their initial values. For example, if a class maintains an array of instances, the initialize method could set up the array and even allocate one or two default instances to have them ready.

The runtime system sends an initialize message to every class object before the class receives any other messages and after its superclass has received the initialize message. This gives the class a chance to set up its runtime environment before it’s used. If no initialization is required, you don’t need to write an initialize method to respond to the message.

Because of inheritance, an initialize message sent to a class that doesn’t implement the initialize method is forwarded to the superclass, even though the superclass has already received the initialize message. For example, assume class A implements the initialize method, and class B inherits from class A but does not implement the initialize method. Just before class B is to rece