The Objective-C Advantage

If you’re a procedural programmer new to object-oriented concepts, it might help at first to think of an object as essentially a structure with functions associated with it. This notion is not too far off the reality, particularly in terms of runtime implementation.

Every Objective-C object hides a data structure whose first member—or instance variable—is the isa pointer. (Most remaining members are defined by the object’s class and superclasses.) The isa pointer, as the name suggests, points to the object’s class, which is an object in its own right (see Figure 2-1) and is compiled from the class definition. The class object maintains a dispatch table consisting essentially of pointers to the methods it implements; it also holds a pointer to its superclass, which has its own dispatch table and superclass pointer. Through this chain of references, an object has access to the method implementations of its class and all its superclasses (as well as all inherited public and protected instance variables). The isa pointer is critical to the message-dispatch mechanism and to the dynamism of Cocoa objects.

This peek behind the object facade gives a highly simplified view of what happens in the Objective-C runtime to enable message-dispatch, inheritance, and other facets of general object behavior. But this information is essential to understanding the major strength of Objective-C, its dynamism.

The Dynamism of Objective-C

Objective-C is a very dynamic language. Its dynamism frees a program from compile-time and link-time constraints and shifts much of the responsibility for symbol resolution to runtime, when the user is in control. Objective-C is more dynamic than other programming languages because its dynamism springs from three sources:

• Dynamic typing—determining the class of an object at runtime

• Dynamic binding—determining the method to invoke at runtime

• Dynamic loading—adding new modules to a program at runtime

For dynamic typing, Objective-C introduces the id data type, which can represent any Cocoa object. A typical use of this generic object type is shown in this part of the code example from Listing 2-2:

id word;

while (word = [enm nextObject]) {

    // do something with 'word' variable....

}

The id data type makes it possible to substitute any type of object at runtime. You can thereby let runtime factors dictate what kind of object is to be used in your code. Dynamic typing permits associations between objects to be determined at runtime rather than forcing them to be encoded in a static design. Static type checking at compile time may ensure stricter data integrity, but in exchange for that stricter integrity, dynamic typing gives your program much greater flexibility. And through object introspection (for example, asking a dynamically typed, anonymous object what its class is) you can still verify the type of an object at runtime and thus validate its suitability for a particular operation. (Of course, you can always statically check the types of objects when you need to.)

Dynamic typing gives substance to dynamic binding, the second kind of dynamism in Objective-C. Just as dynamic typing defers the resolution of an object’s class membership until runtime, dynamic binding defers the decision of which method to invoke until runtime. Method invocations are not bound to code during compilation; they are bound only when a message is actually delivered. With both dynamic typing and dynamic binding, you can obtain different results in your code each time you execute it. Runtime factors determine which receiver is chosen and which method is invoked.

The runtime’s message-dispatch machinery enables dynamic binding. When you send a message to a dynamically typed object, the runtime system uses the receiver’s isa pointer to locate the object’s class, and from there the method implementation to invoke. The method is dynamically bound to the message. And you don’t have to do anything special in your Objective-C code to reap the benefits of dynamic binding. It happens routinely and transparently every time you send a message, especially one to a dynamically typed object.

Dynamic loading, the final type of dynamism, is a feature of Cocoa that depends on Objective-C for runtime support. With dynamic loading, a Cocoa program can load executable code and resources as they’re needed instead of having to load all program components at launch time. The executable code (which is linked prior to loading) often contains new classes that become integrated into the runtime image of the program. Both code and localized resources (including nib files) are packaged in bundles and are explicitly loaded with methods defined in Foundation’s NSBundle class.

This “lazy-loading” of program code and resources improves overall performance by placing lower memory demands on the system. Even more importantly, dynamic loading makes applications extensible. You can devise a plug-in architecture for your application that allows you and other developers to customize it with additional modules that the application can dynamically load months or even years after the application is released. If the design is right, the classes in these modules will not clash with the classes already in place because each class encapsulates its implementation and has its own namespace.

Extensions to the Objective-C Language

Objective-C features four types of extensions that are powerful tools in software development: categories, protocols, declared properties, and fast enumeration. Some extensions introduce different techniques for declaring methods and associating them with a class. Others offer convenient ways to declare and access object properties, enumerate quickly over collections, handle exceptions, and perform other tasks.

#import <Foundation/NSArray.h> // if Foundation not already imported

@interface NSArray (PrettyPrintElements)

- (NSString *)prettyPrintDescription;

@end

#import “PrettyPrintCategory.h”

@implementation NSArray (PrettyPrintElements)

- (NSString *)prettyPrintDescription {

    // implementation code here...

}

@end

@protocol NSCoding

- (void)encodeWithCoder:(NSCoder *)aCoder;

- (id)initWithCoder:(NSCoder *)aDecoder;

@end

@protocol MyProtocol

// implementation of this method is required implicitly

- (void)requiredMethod;

@optional

// implementation of these methods is optional

- (void)anOptionalMethod;

- (void)anotherOptionalMethod;

@required

// implementation of this method is required

- (void)anotherRequiredMethod;

@end

@interface NSData : NSObject <NSCopying, NSMutableCopying, NSCoding>

if ([anObject conformsToProtocol:@protocol(NSCoding)]) {

        // do something appropriate

}

- (void)draggingEnded:(id <NSDraggingInfo>)sender;

@synthesize title, directReports, role = jobDescrip;

NSString *title = employee.title; // assigns employee title to local variable

employee.ID = "A542309"; // assigns literal string to employee ID

// gets last name of this employee's manager

NSString *lname = employee.manager.lastName;

NSArray *array = [NSArray arrayWithObjects:

        @"One", @"Two", @"Three", @"Four", nil];

for (NSString *element in array) {

    NSLog(@"element: %@", element);

}

NSSet *set = [NSSet setWithObjects:

        @"Alpha", @"Beta", @"Gamma", @"Delta", nil];

NSString *setElement;

for (setElement in set) {

    NSLog(@"element: %@", setElement);

}

Using Objective-C

Work gets done in an object-oriented program through messages; one object sends a message to another object. Through the message, the sending object requests something from the receiving object (receiver). It requests that the receiver perform some action, return some object or value, or do both things.

Objective-C adopts a unique syntactical form for messaging. Take the following statement from the SimpleCocoaTool code in Listing 2-2:

NSEnumerator *enm = [sorted_args objectEnumerator];

The message expression is on the right side of the assignment, enclosed by the square brackets. The left-most item in the message expression is the receiver, a variable or expression representing the object to which the message is sent. In this case, the receiver is sorted_args, an instance of the NSArray class. Following the receiver is the message proper, in this case objectEnumerator. (For now, the discussion focuses on message syntax and does not look too deeply into what this and other messages in SimpleCocoaTool actually do.) The message objectEnumerator invokes a method of the sorted_args object named objectEnumerator, which returns a reference to an object that is held by the variable enm on the left side of the assignment. This variable is statically typed as an instance of the NSEnumerator class. You can diagram this statement as:

• NSClassName *variable = [receiver message];

However, this diagram is simplistic and not really accurate. A message consists of a selector name and the parameters of the message. The Objective-C runtime uses a selector name, such as objectEnumerator above, to look up a selector in a table in order to find the method to invoke. A selector is a unique identifier that represents a method and that has a special type, SEL. Because it’s so closely related, the selector name used to look up a selector is frequently called a selector as well. The above statement thus is more correctly shown as:

• NSClassName *variable = [receiver selector];

Messages often have parameters, which are sometimes called arguments. A message with a single parameter affixes a colon to the selector name and puts the parameter right after the colon. This construct is called a keyword ; a keyword ends with a colon, and an parameter follows the colon. Thus we could diagram a message expression with a single parameter (and assignment) as follows:

• NSClassName *variable = [receiver keyword:parameter];

If a message has multiple parameters, the selector has multiple keywords. A selector name includes all keywords, including colons, but does not include anything else, such as return type or parameter types. A message expression with multiple keywords (plus assignment) could be diagrammed as follows:

• NSClassName *variable = [receiver keyword1:param1 keyword2:param2];

As with function parameters, the type of a parameter must match the type specified in the method declaration. Take as an example the following message expression from SimpleCocoaTool:

NSCountedSet *cset = [[NSCountedSet alloc] initWithArray:param];

Here param, which is also an instance of the NSArray class, is the parameter of the message named initWithArray:.

The initWithArray: example cited above is interesting in that it illustrates nesting. With Objective-C, you can nest one message inside another message; the object returned by one message expression is used as the receiver by the message expression that encloses it. So to interpret nested message expressions, start with the inner expression and work your way outward. The interpretation of the above statement would be:

1. The alloc message is sent to the NSCountedSet class, which creates (by allocating memory for it) an uninitialized instance of the class.

2. The initWithArray: message is sent to the uninitialized instance, which initializes itself with the array args and returns a reference to itself.

Next consider this statement from the main routine of SimpleCocoaTool:

NSArray *sorted_args = [[cset allObjects] sortedArrayUsingSelector:@selector(compare:)];

What’s noteworthy about this message expression is the parameter of the sortedArrayUsingSelector: message. This parameter requires the use of the @selector compiler directive to create a selector to be used as a parameter.

Let’s pause a moment to review message and method terminology. A method is essentially a function defined and implemented by the class of which the receiver of a message is a member. A message is a selector name (perhaps consisting of one of more keywords) along with its parameters; a message is sent to a receiver and this results in the invocation (or execution) of the method. A message expression encompasses both receiver and message. Figure 2-2 depicts these relationships.

Objective-C uses a number of defined types and literals that you won’t find in ANSI C. In some cases, these types and literals replace their ANSI C counterparts. Table 2-2 describes a few of the important ones, including the allowable literals for each type.

In your program’s control-flow statements, you can test for the presence (or absence) of the appropriate negative literal to determine how to proceed. For example, the following while statement from the SimpleCocoaTool code implicitly tests the word object variable for the presence of a returned object (or, in another sense, the absence of nil):

while (word = [enm nextObject]) {

    printf("%s\n", [word UTF8String]);

}

In Objective-C, you can often send a message to nil with no ill effects. Return values from messages sent to nil are guaranteed to work as long as what is returned is typed as an object. See Sending Messages to nil in The Objective-C Programming Language for details.

One final thing to note about the SimpleCocoaTool code is something that is not readily apparent if you’re new to Objective-C. Compare this statement:

NSEnumerator *enm = [sorted_args objectEnumerator];

with this one:

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

On the surface, they seem to do identical things; both return a reference to an object. However there is an important semantic difference (for memory-managed code) that has to do with the ownership of the returned object, and hence the responsibility for freeing it. In the first statement, the SimpleCocoaTool program does not own the returned object. In the second statement, the program creates the object and so owns it. The last thing the program does is to send the release message to the created object, thus freeing it. The only other explicitly created object (the NSCountedSet instance) is also explicitly released at the end of the program. For a summary of the memory-management policy for object ownership and disposal, and the methods to use to enforce this policy, see How Memory Management Works.

NSObject

NSObject is the root class of most Objective-C class hierarchies; it has no superclass. From NSObject, other classes inherit a basic interface to the runtime system for the Objective-C language, and its instances obtain their ability to behave as objects.

Although it is not strictly an abstract class, NSObject is virtually one. By itself, an NSObject instance cannot do anything useful beyond being a simple object. To add any attributes and logic specific to your program, you must create one or more classes inheriting from NSObject or from any other class derived from NSObject.

NSObject adopts the NSObject protocol (see Root Class—and Protocol). The NSObject protocol allows for multiple root objects. For example, NSProxy, the other root class, does not inherit from NSObject but adopts the NSObject protocol so that it shares a common interface with other Objective-C objects.

Root Class—and Protocol

NSObject is the name not only of a class but of a protocol. Both are essential to the definition of an object in Cocoa. The NSObject protocol specifies the basic programmatic interface required of all root classes in Cocoa. Thus not only the NSObject class adopts the identically named protocol, but the other Cocoa root class, NSProxy, adopts it as well. The NSObject class further specifies the basic programmatic interface for any Cocoa object that is not a proxy object.

The design of Objective-C uses a protocol such as NSObject in the overall definition of Cocoa objects (rather than making the methods of the protocol part of the class interface) to make multiple root classes possible. Each root class shares a common interface, as defined by the protocols they adopt.

In another sense, NSObject is not the only root protocol. Although the NSObject class does not formally adopt the NSCopying, NSMutableCopying, and NSCoding protocols, it declares and implements methods related to those protocols. (Moreover, the NSObject.h header file, which contains the definition of the NSObject class, also contains the definitions of the root protocols NSObject, NSCopying, NSMutableCopying, and NSCoding.) Object copying, encoding, and decoding are fundamental aspects of object behavior. Many, if not most, subclasses are expected to adopt or conform to these protocols.

Overview of Root-Class Methods

The NSObject root class, along with the adopted NSObject protocol and other root protocols, specify the following interface and behavioral characteristics for all nonproxy Cocoa objects:

• Allocation, initialization, and duplication. Some methods of NSObject (including some from adopted protocols) deal with the creation, initialization, and duplication of objects:

  • The alloc and allocWithZone: methods allocate memory for an object from a memory zone and set the object to point to its runtime class definition.

  • The init method is the prototype for object initialization, the procedure that sets the instance variables of an object to a known initial state. The class methods initialize and load give classes a chance to initialize themselves.

  • The new method is a convenience method that combines simple allocation and initialization.

  • The copy and copyWithZone: methods make copies of any object that is a member of a class implementing these methods (from the NSCopying protocol); the mutableCopy and mutableCopyWithZone: (defined in the NSMutableCopying protocol) are implemented by classes that want to make mutable copies of their objects.

  See Object Creation for more information.

• Object retention and disposal. The following methods are particularly important to an object-oriented program that uses the traditional, and explicit, form of memory management:

  • The retain method increments an object’s retain count.

  • The release method decrements an object’s retain count.

  • The autorelease method also decrements an object’s retain count, but in a deferred fashion.

  • The retainCount method returns an object’s current retain count.

  • The dealloc method is implemented by a class to release its objects’ instance variables and free dynamically allocated memory.

  See How Memory Management Works for more information about explicit memory management.

• Introspection and comparison. Many NSObject methods enable you to make runtime queries about an object. These introspection methods help to discover an object’s position in the class hierarchy, determine whether it implements a certain method, and test whether it conforms to a specific protocol. Some of these are class methods only.

  • The superclass and class methods (class and instance) return the receiver’s superclass and class, respectively, as Class objects.

  • You can determine the class membership of objects with the methods isKindOfClass: and isMemberOfClass:; the latter method is for testing whether the receiver is an instance of the specified class. The class method isSubclassOfClass: tests class inheritance.

  • The respondsToSelector: method tests whether the receiver implements a method identified by a selector. The class method instancesRespondToSelector: tests whether instances of a given class implement the specified method.

  • The conformsToProtocol: method tests whether the receiver (object or class) conforms to a given protocol.

  • The isEqual: and hash methods are used in object comparison.

  • The description method allows an object to return a string describing its contents; this output is often used in debugging (the print-object command) and by the %@ specifier for objects in formatted strings.

  See Introspection for more information.

• Object encoding and decoding. The following methods pertain to object encoding and decoding (as part of the archiving process):

  • The encodeWithCoder: and initWithCoder: methods are the sole members of the NSCoding protocol. The first allows an object to encode its instance variables and the second enables an object to initialize itself from decoded instance variables.

  • The NSObject class declares other methods related to object encoding: classForCoder, replacementObjectForCoder:, and awakeAfterUsingCoder:.

  See Archives and Serializations Programming Guide for further information.

• Message forwarding. The forwardInvocation: method and related methods permit an object to forward a message to another object.

• Message dispatch. A set of methods beginning with performSelector allows you to dispatch messages after a specified delay and to dispatch messages (synchronously or asynchronously) from a secondary thread to the main thread.

NSObject has several other methods, including class methods for versioning and posing (the latter lets a class present itself to the runtime as another class). It also includes methods that let you access runtime data structures, such as method selectors and function pointers to method implementations.

Interface Conventions

Some NSObject methods are meant only to be invoked, whereas others are intended to be overridden. For example, most subclasses should not override allocWithZone:, but they should implement init—or at least an initializer that ultimately invokes the root-class init method (see Object Creation). Of those methods that subclasses are expected to override, the NSObject implementations of those methods either do nothing or return some reasonable default value such as self. These default implementations make it possible to send basic messages such as init to any Cocoa object—even to an object whose class doesn’t override them—without risking a runtime exception. It’s not necessary to check (using respondsToSelector:) before sending the message. More importantly, the “placeholder” methods of NSObject define a common structure for Cocoa objects and establish conventions that, when followed by all classes, make object interactions more reliable.

Instance and Class Methods

The runtime system treats methods defined in the root class in a special way. Instance methods defined in a root class can be performed both by instances and by class objects. Therefore, all class objects have access to the instance methods defined in the root class. Any class object can perform any root instance method, provided it doesn’t have a class method with the same name.

For example, a class object could be sent messages to perform the NSObject instance methods respondsToSelector: and performSelector:withObject:, as shown in this example:

SEL method = @selector(riskAll:);

if ([MyClass respondsToSelector:method])

    [MyClass performSelector:method withObject:self];

Note that the only instance methods available to a class object are those defined in its root class. In the example above, if MyClass had reimplemented either respondsToSelector: or performSelector:withObject:, those new versions would be available only to instances. The class object for MyClass could perform only the versions defined in the NSObject class. (Of course, if MyClass had implemented respondsToSelector: or performSelector:withObject: as class methods rather than instance methods, the class would perform those new versions.)

How the Garbage Collector Works

The work of garbage collection is done by an entity known as the garbage collector. To the garbage collector, objects in a program are either reachable or are not reachable. Periodically the collector scans through the objects and collects those that are reachable. Those objects that aren’t reachable—the garbage objects—are finalized (that is, their finalize method is invoked). Subsequently, the memory they had occupied is freed.

The critical notion behind the architecture of the Objective-C garbage collector is the set of factors that constitute a reachable object. These factors start with an initial root set of objects: global variables (including NSApp), stack variables, and objects with external references (that is, outlets). The objects of the initial root set are never treated as garbage and therefore persist throughout the runtime life of the program. The collector adds to this initial set all objects that are directly reachable through strong references as well as all possible references found in the call stacks of every Cocoa thread. The garbage collector recursively follows strong references from the root set of objects to other objects, and from those objects to other objects, until all potentially reachable objects have been accounted for. (All references from one object to another object are considered strong references by default; weak references have to be explicitly marked as such.) In other words, a nonroot object persists at the end of a collection cycle only if the collector can reach it via strong references from a root object.

Figure 2-3 illustrates the general path the collector follows when it looks for reachable objects. But it also shows a few other important aspects of the garbage collector. The collector scans only a portion of a Cocoa program’s virtual memory for reachable objects. Scanned memory includes the call stacks of threads, global variables, and the auto zone, an area of memory from which all garbage-collected blocks of memory are dispensed. The collector does not scan the malloc zone, which is the zone from which blocks of memory are allocated via the malloc function.

Another thing the diagram illustrates is that objects may have strong references to other objects, but if there is no chain of strong references that leads back to a root object, the object is considered unreachable and is disposed of at the end of a collection cycle. These references can be circular, but in garbage collection the circular references do not cause memory leaks, as do retain cycles in memory-managed code. All of these objects are disposed of when they are no longer reachable.

The Objective-C garbage collector is request-driven, not demand-driven. It initiates collection cycles only upon request; Cocoa makes requests at intervals optimized for performance or when a certain memory threshold has been exceeded. You can also request collections using methods of the NSGarbageCollector class. The garbage collector is also generational. It makes not only exhaustive, or full, collections of program objects periodically, but it makes incremental collections based on the “generation” of objects. A object’s generation is determined by when it was allocated. Incremental collections, which are faster and more frequent than full collections, affect the more recently allocated objects. (Most objects are assumed to “die young”; if an object survives the first collection, it is likely to be intended to have a longer life.)

The garbage collector runs on one thread of a Cocoa program. During a collection cycle it will stop secondary threads to determine which objects in those threads are unreachable. But it never stops all threads at once, and it stops each thread for as short a time as possible. The collector is also conservative in that it never compacts auto-zone memory by relocating blocks of memory or updating pointers; once allocated, an object always stays in its original memory location.

How Memory Management Works

In memory-managed Objective-C code, a Cocoa object exists over a life span which, potentially at least, has distinct stages. It is created, initialized, and used (that is, other objects send messages to it). It is possibly retained, copied, or archived, and eventually it is released and destroyed. The following discussion charts the life of a typical object without going into much detail—yet.

Let’s begin at the end, at the way objects are disposed of when garbage collection is turned off. In this context Cocoa and Objective-C opt for a voluntary, policy-driven procedure for keeping objects around and disposing of them when they’re no longer needed.

This procedure and policy rest on the notion of reference counting. Each Cocoa object carries with it an integer indicating the number of other objects (or even procedural code sites) that are interested in its persistence. This integer is referred to as the object’s retain count (“retain” is used to avoid overloading the term “reference”). When you create an object, either by using a class factory method or by using the alloc or allocWithZone: class methods, Cocoa does a couple of very important things:

• It sets the object’s isa pointer—the NSObject class's sole public instance variable—to point to the object’s class, thus integrating the object into the runtime’s view of the class hierarchy. (See Object Creation for further information.)

• It sets the object’s retain count—a kind of hidden instance variable managed by the runtime—to one. (The assumption here is that an object’s creator is interested in its persistence.)

After object allocation, you generally initialize an object by setting its instance variables to reasonable initial values. (NSObject declares the init method as the prototype for this purpose.) The object is now ready to be used; you can send messages to it, pass it to other objects, and so on.

When you release an object—that is, send a release message to it—NSObject decrements its retain count. If the retain count falls from one to zero, the object is deallocated. Deallocation takes place in two steps. First, the object’s dealloc method is invoked to release instance variables and free dynamically allocated memory. Then the operating system destroys the object itself and reclaims the memory the object once occupied.

What if you don’t want an object to go away any time soon? If after receiving an object from somewhere you send it a retain message, the object’s retain count is incremented to two. Now two release messages are required before deallocation occurs. Figure 2-4 depicts this rather simplistic scenario.

Of course, in this scenario the creator of an object has no need to retain the object. It owns the object already. But if this creator were to pass the object to another object in a message, the situation changes. In an Objective-C program, an object received from some other object is always assumed to be valid within the scope in which it is obtained. The receiving object can send messages to the received object and can pass it to other objects. This assumption requires the sending object to behave appropriately and not prematurely free the object while a client object has a reference to it.

If the client object wants to keep the received object around after it goes out of programmatic scope, it can retain it—that is, send it a retain message. Retaining an object increments its retain count, thereby expressing an ownership interest in the object. The client object assumes a responsibility to release the object at some later time. If the creator of an object releases it, but a client object has retained that same object, the object persists until the client releases it. Figure 2-5 illustrates this sequence.

Instead of retaining an object, you could copy it by sending it a copy or copyWithZone: message. (Many, if not most, subclasses encapsulating some kind of data adopt or conform to this protocol.) Copying an object not only duplicates it but almost always resets its retain count to one (see Figure 2-6). The copy can be shallow or deep, depending on the nature of the object and its intended usage. A deep copy duplicates the objects held as instance variables of the copied object, whereas a shallow copy duplicates only the references to those instance variables.

In terms of usage, what differentiates copy from retain is that the former claims the object for the sole use of the new owner; the new owner can mutate the copied object without regard to its origin. Generally you copy an object instead of retaining it when it is a value object—that is, an object encapsulating some primitive value. This is especially true when that object is mutable, such as an instance of NSMutableString. For immutable objects, copy and retain can be equivalent and might be implemented similarly.

You might have noticed a potential problem with this scheme for managing the object life cycle. An object that creates an object and passes it to another object cannot always know when it can release the object safely. There could be multiple references to that object on the call stack, some by objects unknown to the creating object. If the creating object releases the created object and then some other object sends a message to that now-destroyed object, the program could crash. To get around this problem, Cocoa introduces a mechanism for deferred deallocation called autoreleasing.

Autoreleasing makes use of autorelease pools (defined by the NSAutoreleasePool class). An autorelease pool is a collection of objects within an explicitly defined scope that are marked for eventual release. Autorelease pools can be nested. When you send an object an autorelease message, a reference to that object is put into the most immediate autorelease pool. It is still a valid object, so other objects within the scope defined by the autorelease pool can send messages to it. When program execution reaches the end of the scope, the pool is released and, as a consequence, all objects in the pool are released as well (see Figure 2-7). If you are developing an application you may not need to set up an autorelease pool; the AppKit framework automatically sets up an autorelease pool scoped to the application’s event cycle.

So far the discussion of the object life cycle has focused on the mechanics of managing objects through that cycle. But a policy of object ownership guides the use of these mechanisms. This policy can be summarized as follows:

• If you create an object by allocating and initializing it (for example, [[MyClass alloc] init]), you own the object and are responsible for releasing it. This rule also applies if you use the NSObject convenience method new.

• If you copy an object, you own the copied object and are responsible for releasing it.

• If you retain an object, you have partial ownership of the object and must release it when you no longer need it.

Conversely, if you receive an object from some other object, you do not own the object and should not release it. (There are a handful of exceptions to this rule, which are explicitly noted in the reference documentation.)

As with any set of rules, there are exceptions and “gotchas”:

• If you create an object using a class factory method (such as the NSMutableArray arrayWithCapacity: method), assume that the object you receive has been autoreleased. You should not release the object yourself and should retain it if you want to keep it around.

• To avoid cyclic references, a child object should never retain its parent. (A parent is the creator of the child or is an object holding the child as an instance variable.)

If you do not follow this ownership policy, two bad things are likely to happen in your Cocoa program. Because you did not release created, copied, or retained objects, your program is now leaking memory. Or your program crashes because you sent a message to an object that was deallocated out from under you. And here’s a further caveat: Debugging these problems can be a time-consuming affair.

A further basic event that could happen to an object during its life cycle is archiving. Archiving converts the web of interrelated objects that constitute an object-oriented program—the object graph—into a persistent form (usually a file) that preserves the identity and relationships of each object in the graph. When the program is unarchived, its object graph is reconstructed from this archive. To participate in archiving (and unarchiving), an object must be able to encode (and decode) its instance variables using the methods of the NSCoder class. NSObject adopts the NSCoding protocol for this purpose. For more information on the archiving of objects, see Archives and Serializations Programming Guide.

Allocating an Object

When you allocate an object, part of what happens is what you might expect, given the term allocate. Cocoa allocates enough memory for the object from a region of application virtual memory. To calculate how much memory to allocate, it takes the object’s instance variables into account—including their types and order—as specified by the object’s class.

To allocate an object, you send the message alloc or allocWithZone: to the object’s class. In return, you get a “raw” (uninitialized) instance of the class. The alloc variant of the method uses the application’s default zone. A zone is a page-aligned area of memory for holding related objects and data allocated by an application. See Advanced Memory Management Programming Guide for more information on zones.

An allocation message does other important things besides allocating memory:

• It sets the object’s retain count to one (as described in How Memory Management Works).

• It initializes the object’s isa instance variable to point to the object’s class, a runtime object in its own right that is compiled from the class definition.

• It initializes all other instance variables to zero (or to the equivalent type for zero, such as nil, NULL, and 0.0).

An object’s isa instance variable is inherited from NSObject, so it is common to all Cocoa objects. After allocation sets isa to the object’s class, the object is integrated into the runtime’s view of the inheritance hierarchy and the current network of objects (class and instance) that constitute a program. Consequently an object can find whatever information it needs at runtime, such as another object’s place in the inheritance hierarchy, the protocols that other objects conform to, and the location of the method implementations it can perform in response to messages.

In summary, allocation not only allocates memory for an object but initializes two small but very important attributes of any object: its isa instance variable and its retain count. It also sets all remaining instance variables to zero. But the resulting object is not yet usable. Initializing methods such as init must yet initialize objects with their particular characteristics and return a functional object.

Initializing an Object

Initialization sets the instance variables of an object to reasonable and useful initial values. It can also allocate and prepare other global resources needed by the object, loading them if necessary from an external source such as a file. Every object that declares instance variables should implement an initializing method—unless the default set-everything-to-zero initialization is sufficient. If an object does not implement an initializer, Cocoa invokes the initializer of the nearest ancestor instead.

id anObject = [[MyClass alloc] init];

if (anObject) {

    [anObject doSomething];

    // more messages...

} else {

    // handle error

}

id myObject = [MyClass alloc];

[myObject init];

[myObject doSomething];

id myObject = [[MyClass alloc] init];

if ( myObject ) {

    [myObject doSomething];

} else {

    // error recovery...

}

NSString *aStr = [[NSString alloc] initWithString:@"Foo"];

aStr = [aStr initWithString:@"Bar"];

Implementing an Initializer

There are several critical rules to follow when implementing an init... method that serves as a class’s sole initializer or, if there are multiple initializers, its designated initializer (described in Multiple Initializers and the Designated Initializer):

• Always invoke the superclass (super) initializer first.

• Check the object returned by the superclass. If it is nil, then initialization cannot proceed; return nil to the receiver.

• When initializing instance variables that are references to objects, retain or copy the object as necessary (in memory-managed code).

• After setting instance variables to valid initial values, return self unless:

  • It was necessary to return a substituted object, in which case release the freshly allocated object first (in memory-managed code).

  • A problem prevented initialization from succeeding, in which case return nil.

The method in Listing 2-3 illustrates these rules.

Listing 2-3  An example of an initializer

- (id)initWithAccountID:(NSString *)identifier {

if ( self = [super init] ) {

Account *ac = [accountDictionary objectForKey:identifier];

if (ac) { // object with that ID already exists

[self release];

return [ac retain];

}

if (identifier) {

accountID = [identifier copy]; // accountID is instance variable

[accountDictionary setObject:self forKey:identifier];

return self;

} else {

[self release];

return nil;

}

} else

return nil;

}

It isn’t necessary to initialize all instance variables of an object explicitly, just those that are necessary to make the object functional. The default set-to-zero initialization performed on an instance variable during allocation is often sufficient. Make sure that you retain or copy instance variables, as required for memory management.

The requirement to invoke the superclass’s initializer as the first action is important. Recall that an object encapsulates not only the instance variables defined by its class but the instance variables defined by all of its ancestor classes. By invoking the initializer of super first, you help to ensure that the instance variables defined by classes up the inheritance chain are initialized first. The immediate superclass, in its initializer, invokes the initializer of its superclass, which invokes the main init... method of its superclass, and so on (see Figure 2-8). The proper order of initialization is critical because the later initializations of subclasses may depend on superclass-defined instance variables being initialized to reasonable values.

Inherited initializers are a concern when you create a subclass. Sometimes a superclass init... method sufficiently initializes instances of your class. But because it is more likely it won’t, you should override the superclass’s initializer. If you don’t, the superclass’s implementation is invoked, and because the superclass knows nothing about your class, your instances may not be correctly initialized.

Multiple Initializers and the Designated Initializer

A class can define more than one initializer. Sometimes multiple initializers let clients of the class provide the input for the same initialization in different forms. The NSSet class, for example, offers clients several initializers that accept the same data in different forms; one takes an NSArray object, another a counted list of elements, and another a nil-terminated list of elements:

- (id)initWithArray:(NSArray *)array;

- (id)initWithObjects:(id *)objects count:(unsigned)count;

- (id)initWithObjects:(id)firstObj, ...;

Some subclasses provide convenience initializers that supply default values to an initializer that takes the full complement of initialization parameters. This initializer is usually the designated initializer, the most important initializer of a class. For example, assume there is a Task class and it declares a designated initializer with this signature:

- (id)initWithTitle:(NSString *)aTitle date:(NSDate *)aDate;

The Task class might include secondary, or convenience, initializers that simply invoke the designated initializer, passing it default values for those parameters the secondary initializer doesn’t explicitly request (Listing 2-4).

Listing 2-4  Secondary initializers

- (id)initWithTitle:(NSString *)aTitle {

return [self initWithTitle:aTitle date:[NSDate date]];

}

- (id)init {

return [self initWithTitle:@”Task”];

}

The designated initializer plays an important role for a class. It ensures that inherited instance variables are initialized by invoking the designated initializer of the superclass. It is typically the init... method that has the most parameters and that does most of the initialization work, and it is the initializer that secondary initializers of the class invoke with messages to self.

When you define a subclass, you must be able to identify the designated initializer of the superclass and invoke it in your subclass’s designated initializer through a message to super. You must also make sure that inherited initializers are covered in some way. And you may provide as many convenience initializers as you deem necessary. When designing the initializers of your class, keep in mind that designated initializers are chained to each other through messages to super; whereas other initializers are chained to the designated initializer of their class through messages to self.

An example will make this clearer. Let’s say there are three classes, A, B, and C; class B inherits from class A, and class C inherits from class B. Each subclass adds an attribute as an instance variable and implements an init... method—the designated initializer—to initialize this instance variable. They also define secondary initializers and ensure that inherited initializers are overridden, if necessary. Figure 2-9 illustrates the initializers of all three classes and their relationships.

The designated initializer for each class is the initializer with the most coverage; it is the method that initializes the attribute added by the subclass. The designated initializer is also the init... method that invokes the designated initializer of the superclass in a message to super. In this example, the designated initializer of class C, initWithTitle:date:, invokes the designated initializer of its superclass, initWithTitle:, which in turn invokes the init method of class A. When creating a subclass, it’s always important to know the designated initializer of the superclass.

Although designated initializers are thus connected up the inheritance chain through messages to super, secondary initializers are connected to their class’s designated initializer through messages to self. Secondary initializers (as in this example) are frequently overridden versions of inherited initializers. Class C overrides initWithTitle: to invoke its designated initializer, passing it a default date. This designated initializer, in turn, invokes the designated initializer of class B, which is the overridden method, initWithTitle:. If you sent an initWithTitle: message to objects of class B and class C, you’d be invoking different method implementations. On the other hand, if class C did not override initWithTitle: and you sent the message to an instance of class C, the class B implementation would be invoked. Consequently, the C instance would be incompletely initialized (since it would lack a date). When creating a subclass, it’s important to make sure that all inherited initializers are adequately covered.

Sometimes the designated initializer of a superclass may be sufficient for the subclass, and so there is no need for the subclass to implement its own designated initializer. Other times, a class’s designated initializer may be an overridden version of its superclass's designated initializer. This is frequently the case when the subclass needs to supplement the work performed by the superclass’s designated initializer, even though the subclass does not add any instance variables of its own (or the instance variables it does add don’t require explicit initialization).

The dealloc and finalize Methods

In Cocoa classes that use garbage collection, the finalize method is where the class disposes of any remaining resources and attachments of its instances before those instances are freed. In Cocoa classes that use traditional memory management, the comparable method for resource cleanup is the dealloc method. Although similar in purpose, there are significant differences in how these methods should be implemented.

In many respects, the dealloc method is the counterpart to a class’s init... method, especially its designated initializer. Instead of being invoked just after the allocation of an object, dealloc is invoked just prior to the object’s destruction. Instead of ensuring that the instance variables of an object are properly initialized, the dealloc method makes sure that object instance variables are released and that any dynamically allocated memory has been freed.

The final point of parallelism has to do with the invocation of the superclass implementation of the same method. In an initializer, you invoke the superclass's designated initializer as the first step. In dealloc, you invoke the superclass's implementation of dealloc as the last step. The reason for this order of invocation is mirror-opposite to that for initializers; subclasses should release or free the instance variables they own first before the instance variables of ancestor classes are released or freed.

Listing 2-5 shows how you might implement this method.

Listing 2-5  A typical dealloc method

- (void)dealloc {

    [accountDictionary release];

    free(mallocdChunk);

    [super dealloc];

}

Note that this example does not verify that accountDictionary (an instance variable) is something other than nil before releasing it. That is because Objective-C lets you safely send a message to nil.

Similar to the dealloc method, the finalize method is the place to close resources used by an object in a garbage-collected environment prior to that object being freed and its memory reclaimed. As in dealloc, the final line of a finalize implementation should invoke the superclass implementation of the method. However, unlike dealloc, a finalize implementation does not have to release instance variables because the garbage collector destroys these objects at the proper time.

But there is a more significant difference between the dealloc and finalize methods. Whereas implementing a dealloc method is usually required, you should not implement a finalize method if possible. And, if you must implement finalize, you should reference as few other objects as possible. The primary reason for this admonition is that the order in which garbage-collected objects are sent finalize messages is indeterminate, even if there are references between them. Thus the consequences are indeterminate, and potentially negative, if messages pass between objects being finalized. Your code cannot depend on the side effects arising from the order of deallocation, as it can in dealloc. Generally, you should try to design your code so that such actions as freeing memory allocated with malloc, closing file descriptors, and unregistering observers happen before finalize is invoked.

Class Factory Methods

Class factory methods are implemented by a class as a convenience for clients. They combine allocation and initialization in one step and return the created object. However, the client receiving this object does not own the object and thus (per the object-ownership policy) is not responsible for releasing it. These methods are of the form + (type)className... (where className excludes any prefix).

Cocoa provides plenty of examples, especially among the “value” classes. NSDate includes the following class factory methods:

+ (id)dateWithTimeIntervalSinceNow:(NSTimeInterval)secs;

+ (id)dateWithTimeIntervalSinceReferenceDate:(NSTimeInterval)secs;

+ (id)dateWithTimeIntervalSince1970:(NSTimeInterval)secs;

And NSData offers the following factory methods:

+ (id)dataWithBytes:(const void *)bytes length:(unsigned)length;

+ (id)dataWithBytesNoCopy:(void *)bytes length:(unsigned)length;

+ (id)dataWithBytesNoCopy:(void *)bytes length:(unsigned)length

        freeWhenDone:(BOOL)b;

+ (id)dataWithContentsOfFile:(NSString *)path;

+ (id)dataWithContentsOfURL:(NSURL *)url;

+ (id)dataWithContentsOfMappedFile:(NSString *)path;

Factory methods can be more than a simple convenience. They can not only combine allocation and initialization, but the allocation can inform the initialization. As an example, let’s say you must initialize a collection object from a property-list file that encodes any number of elements for the collection (NSString objects, NSData objects, NSNumber objects, and so on). Before the factory method can know how much memory to allocate for the collection, it must read the file and parse the property list to determine how many elements there are and what object type these elements are.

Another purpose for a class factory method is to ensure that a certain class (NSWorkspace, for example) vends a singleton instance. Although an init... method could verify that only one instance exists at any one time in a program, it would require the prior allocation of a “raw” instance and then, in memory-managed code, would have to release that instance. A factory method, on the other hand, gives you a way to avoid blindly allocating memory for an object that you might not use (see Listing 2-6).

Listing 2-6  A factory method for a singleton instance

static AccountManager *DefaultManager = nil;

+ (AccountManager *)defaultManager {

    if (!DefaultManager) DefaultManager = [[self allocWithZone:NULL] init];

    return DefaultManager;

}

Evaluating Inheritance Relationships

Once you know the class an object belongs to, you probably know quite a bit about the object. You might know what its capabilities are, what attributes it represents, and what kinds of messages it can respond to. Even if after introspection you are unfamiliar with the class to which an object belongs, you now know enough to not send it certain messages.

The NSObject protocol declares several methods for determining an object’s position in the class hierarchy. These methods operate at different granularities. The class and superclass instance methods, for example, return the Class objects representing the class and superclass, respectively, of the receiver. These methods require you to compare one Class object with another. Listing 2-7 gives a simple (one might say trivial) example of their use.

Listing 2-7  Using the class and superclass methods

// ...

while ( id anObject = [objectEnumerator nextObject] ) {

    if ( [self class] == [anObject superclass] ) {

        // do something appropriate...

    }

}

More commonly, to check an object’s class affiliation, you would send it a isKindOfClass: or isMemberOfClass: message. The former method returns whether the receiver is an instance of a given class or an instance of any class that inherits from that class. A isMemberOfClass: message, on the other hand, tells you if the receiver is an instance of the specified class. The isKindOfClass: method is generally more useful because from it you can know at once the complete range of messages you can send to an object. Consider the code snippet in Listing 2-8.

Listing 2-8  Using isKindOfClass:

if ([item isKindOfClass:[NSData class]]) {

    const unsigned char *bytes = [item bytes];

    unsigned int length = [item length];

    // ...

}

By learning that the object item inherits from the NSData class, this code knows it can send it the NSData bytes and length messages. The difference between isKindOfClass: and isMemberOfClass: becomes apparent if you assume that item is an instance of NSMutableData. If you use isMemberOfClass: instead of isKindOfClass:, the code in the conditionalized block is never executed because item is not an instance of NSData but rather of NSMutableData, a subclass of NSData.

Method Implementation and Protocol Conformance

Two of the more powerful introspection methods of NSObject are respondsToSelector: and conformsToProtocol:. These methods tell you, respectively, whether an object implements a certain method and whether an object conforms to a specified formal protocol (that is, adopts the protocol, if necessary, and implements all the methods of the protocol).

You use these methods in a similar situation in your code. They enable you to discover whether some potentially anonymous object can respond appropriately to a particular message or set of messages before you send it any of those messages. By making this check before sending a message, you can avoid the risk of runtime exceptions resulting from unrecognized selectors. The AppKit framework implements informal protocols—the basis of delegation—by checking whether delegates implement a delegation method (using respondsToSelector:) prior to invoking that method.

Listing 2-9 illustrates how you might use the respondsToSelector: method in your code.

Listing 2-9  Using respondsToSelector:

- (void)doCommandBySelector:(SEL)aSelector {

    if ([self respondsToSelector:aSelector]) {

        [self performSelector:aSelector withObject:nil];

    } else {

        [_client doCommandBySelector:aSelector];

    }

}

Listing 2-10 illustrates how you might use the conformsToProtocol: method in your code.

Listing 2-10  Using conformsToProtocol:

// ...

if (!([((id)testObject) conformsToProtocol:@protocol(NSMenuItem)])) {

    NSLog(@"Custom MenuItem, '%@', not loaded; it must conform to the

        'NSMenuItem' protocol.\n", [testObject class]);

    [testObject release];

    testObject = nil;

}

Object Comparison

Although they are not strictly introspection methods, the hash and isEqual: methods fulfill a similar role. They are indispensable runtime tools for identifying and comparing objects. But instead of querying the runtime for information about an object, they rely on class-specific comparison logic.

The hash and isEqual: methods, both declared by the NSObject protocol, are closely related. The hash method must be implemented to return an integer that can be used as a table address in a hash table structure. If two objects are equal (as determined by the isEqual: method), they must have the same hash value. If your object could be included in collections such as NSSet objects, you need to define hash and verify the invariant that if two objects are equal, they return the same hash value. The default NSObject implementation of isEqual: simply checks for pointer equality.

Using the isEqual: method is straightforward; it compares the receiver against the object supplied as a parameter. Object comparison frequently informs runtime decisions about what should be done with an object. As Listing 2-11 illustrates, you can use isEqual: to decide whether to perform an action, in this case to save user preferences that have been modified.

Listing 2-11  Using isEqual:

- (void)saveDefaults {

    NSDictionary *prefs = [self preferences];

    if (![origValues isEqual:prefs])

        [Preferences savePreferencesToDefaults:prefs];

}

If you are creating a subclass, you might need to override isEqual: to add further checks for points of equality. The subclass might define an extra attribute that has to be the same value in two instances for them to be considered equal. For example, say you create a subclass of NSObject called MyWidget that contains two instance variables, name and data. Both of these must be the same value for two instances of MyWidget to be considered equal. Listing 2-12 illustrates how you might implement isEqual: for the MyWidget class.

Listing 2-12  Overriding isEqual:

- (BOOL)isEqual:(id)other {

    if (other == self)

        return YES;

    if (!other || ![other isKindOfClass:[self class]])

        return NO;

    return [self isEqualToWidget:other];

}

- (BOOL)isEqualToWidget:(MyWidget *)aWidget {

    if (self == aWidget)

        return YES;

    if (![(id)[self name] isEqual:[aWidget name]])

        return NO;

    if (![[self data] isEqualToData:[aWidget data]])

        return NO;

    return YES;

}

This isEqual: method first checks for pointer equality, then class equality, and finally invokes an object comparator whose name indicates the class of object involved in the comparison. This type of comparator, which forces type checking of the object passed in, is a common convention in Cocoa; the isEqualToString: method of the NSString class and the isEqualToTimeZone: method of the NSTimeZone class are but two examples. The class-specific comparator—isEqualToWidget: in this case—performs the checks for name and data equality.

In all isEqualToType: methods of the Cocoa frameworks, nil is not a valid parameter and implementations of these methods may raise an exception upon receiving a nil. However, for backward compatibility, isEqual: methods of the Cocoa frameworks do accept nil, returning NO.

Why Mutable and Immutable Object Variants?

Objects by default are mutable. Most objects allow you to change their encapsulated data through setter accessor methods. For example, you can change the size, positioning, title, buffering behavior, and other characteristics of an NSWindow object. A well-designed model object—say, an object representing a customer record—requires setter methods to change its instance data.

The Foundation framework adds some nuance to this picture by introducing classes that have mutable and immutable variants. The mutable subclasses are typically subclasses of their immutable superclass and have “Mutable” embedded in the class name. These classes include the following:

• NSMutableArray

• NSMutableDictionary

• NSMutableSet

• NSMutableIndexSet

• NSMutableCharacterSet

• NSMutableData

• NSMutableString

• NSMutableAttributedString

• NSMutableURLRequest

Although these classes have atypical names, they are closer to the mutable norm than their immutable counterparts. Why this complexity? What purpose does having an immutable variant of a mutable object serve?

Consider a scenario where all objects are capable of being mutated. In your application you invoke a method and are handed back a reference to an object representing a string. You use this string in your user interface to identify a particular piece of data. Now another subsystem in your application gets its own reference to that same string and decides to mutate it. Suddenly your label has changed out from under you. Things can become even more dire if, for instance, you get a reference to an array that you use to populate a table view. The user selects a row corresponding to an object in the array that has been removed by some code elsewhere in the program, and problems ensue. Immutability is a guarantee that an object won’t unexpectedly change in value while you’re using it.

Objects that are good candidates for immutability are ones that encapsulate collections of discrete values or contain values that are stored in buffers (which are themselves kinds of collections, either of characters or bytes). But not all such value objects necessarily benefit from having mutable versions. Objects that contain a single simple value, such as instances of NSNumber or NSDate, are not good candidates for mutability. When the represented value changes in these cases, it makes more sense to replace the old instance with a new instance.

Performance is also a reason for immutable versions of objects representing things such as strings and dictionaries. Mutable objects for basic entities such as strings and dictionaries bring some overhead with them. Because they must dynamically manage a changeable backing store—allocating and deallocating chunks of memory as needed—mutable objects can be less efficient than their immutable counterparts.

Although in theory immutability guarantees that an object’s value is stable, in practice this guarantee isn’t always assured. A method may choose to hand out a mutable object under the return type of its immutable variant; later, it may decide to mutate the object, possibly violating assumptions and choices the recipient has made based on the earlier value. The mutability of an object itself may change as it undergoes various transformations. For example, serializing a property list (using the NSPropertyListSerialization class) does not preserve the mutability aspect of objects, only their general kind—a dictionary, an array, and so on. Thus, when you deserialize this property list, the resulting objects might not be of the same class as the original objects. For instance, what was once an NSMutableDictionary object might now be a NSDictionary object.

Programming with Mutable Objects

When the mutability of objects is an issue, it’s best to adopt some defensive programming practices. Here are a few general rules or guidelines:

• Use a mutable variant of an object when you need to modify its contents frequently and incrementally after it has been created.

• Sometimes it’s preferable to replace one immutable object with another; for example, most instance variables that hold string values should be assigned immutable NSString objects that are replaced with setter methods.

• Rely on the return type for indications of mutability.

• If you have any doubts about whether an object is, or should be, mutable, go with immutable.

This section explores the gray areas in these guidelines, discussing typical choices you have to make when programming with mutable objects. It also gives an overview of methods in the Foundation framework for creating mutable objects and for converting between mutable and immutable object variants.

NSMutableDictionary *mutDict = [[NSMutableDictionary alloc] init];

NSMutableArray *mutArray = [NSMutableArray arrayWithCapacity:[timeZones count]];

NSMutableSet *mutSet = [aSet mutableCopy];

@interface MyClass : NSObject {

    // ...

    NSMutableSet *widgets;

}

// ...

@end

@implementation MyClass

- (NSSet *)widgets {

    return (NSSet *)[[widgets copy] autorelease];

}

if ( [anArray isKindOfClass:[NSMutableArray class]] ) {

    // add, remove objects from anArray

}

static NSArray *snapshot = nil;

- (void)myFunction {

    NSArray *thingArray = [otherObj things];

    if (snapshot) {

        if ( ![thingArray isEqualToArray:snapshot] ) {

            [self updateStateWith:thingArray];

        }

    }

    snapshot = [thingArray copy];

}

Without Class Clusters: Simple Concept but Complex Interface

To illustrate the class cluster architecture and its benefits, consider the problem of constructing a class hierarchy that defines objects to store numbers of different types (char, int, float, double). Because numbers of different types have many features in common (they can be converted from one type to another and can be represented as strings, for example), they could be represented by a single class. However, their storage requirements differ, so it’s inefficient to represent them all by the same class. Taking this fact into consideration, one could design the class architecture depicted in Figure 2-10 to solve the problem.

Number is the abstract superclass that declares in its methods the operations common to its subclasses. However, it doesn’t declare an instance variable to store a number. The subclasses declare such instance variables and share in the programmatic interface declared by Number.

So far, this design is relatively simple. However, if the commonly used modifications of these basic C types are taken into account, the class hierarchy diagram looks more like Figure 2-11.

The simple concept—creating a class to hold number values—can easily burgeon to over a dozen classes. The class cluster architecture presents a design that reflects the simplicity of the concept.

With Class Clusters: Simple Concept and Simple Interface

Applying the class cluster design pattern to this problem yields the class hierarchy in Figure 2-12 (private classes are in gray).

Users of this hierarchy see only one public class, Number, so how is it possible to allocate instances of the proper subclass? The answer is in the way the abstract superclass handles instantiation.

Creating Instances

The abstract superclass in a class cluster must declare methods for creating instances of its private subclasses. It’s the superclass’s responsibility to dispense an object of the proper subclass based on the creation method that you invoke—you don’t, and can’t, choose the class of the instance.

In the Foundation framework, you generally create an object by invoking a +className... method or the alloc... and init... methods. Taking the Foundation framework’s NSNumber class as an example, you could send these messages to create number objects:

NSNumber *aChar = [NSNumber numberWithChar:’a’];

NSNumber *anInt = [NSNumber numberWithInt:1];

NSNumber *aFloat = [NSNumber numberWithFloat:1.0];

NSNumber *aDouble = [NSNumber numberWithDouble:1.0];

You are not responsible for releasing the objects returned from factory methods; see Class Factory Methods for more information. Many classes also provide the standard alloc... and init... methods to create objects that require you to manage their deallocation.

Each object returned—aChar, anInt, aFloat, and aDouble—may belong to a different private subclass (and in fact does). Although each object’s class membership is hidden, its interface is public, being the interface declared by the abstract superclass, NSNumber. Although it is not precisely correct, it’s convenient to consider the aChar, anInt, aFloat, and aDouble objects to be instances of the NSNumber class, because they’re created by NSNumber class methods and accessed through instance methods declared by NSNumber.

Class Clusters with Multiple Public Superclasses

In the example above, one abstract public class declares the interface for multiple private subclasses. This is a class cluster in the purest sense. It’s also possible, and often desirable, to have two (or possibly more) abstract public classes that declare the interface for the cluster. This is evident in the Foundation framework, which includes the clusters listed in Table 2-3.

Other clusters of this type also exist, but these clearly illustrate how two abstract nodes cooperate in declaring the programmatic interface to a class cluster. In each of these clusters, one public node declares methods that all cluster objects can respond to, and the other node declares methods that are only appropriate for cluster objects that allow their contents to be modified.

This factoring of the cluster’s interface helps make an object-oriented framework’s programmatic interface more expressive. For example, imagine an object representing a book that declares this method:

- (NSString *)title;

The book object could return its own instance variable or create a new string object and return that—it doesn’t matter. It’s clear from this declaration that the returned string can’t be modified. Any attempt to modify the returned object will elicit a compiler warning.

Creating Subclasses Within a Class Cluster

The class cluster architecture involves a trade-off between simplicity and extensibility: Having a few public classes stand in for a multitude of private ones makes it easier to learn and use the classes in a framework but somewhat harder to create subclasses within any of the clusters. However, if it’s rarely necessary to create a subclass, then the cluster architecture is clearly beneficial. Clusters are used in the Foundation framework in just these situations.

If you find that a cluster doesn’t provide the functionality your program needs, then a subclass may be in order. For example, imagine that you want to create an array object whose storage is file-based rather than memory-based, as in the NSArray class cluster. Because you are changing the underlying storage mechanism of the class, you’d have to create a subclass.

On the other hand, in some cases it might be sufficient (and easier) to define a class that embeds within it an object from the cluster. Let’s say that your program needs to be alerted whenever some data is modified. In this case, creating a simple class that wraps a data object that the Foundation framework defines may be the best approach. An object of this class could intervene in messages that modify the data, intercepting the messages, acting on them, and then forwarding them to the embedded data object.

In summary, if you need to manage your object’s storage, create a true subclass. Otherwise, create a composite object, one that embeds a standard Foundation framework object in an object of your own design. The following sections give more detail on these two approaches.

#import <foundation/foundation.h>

@interface MonthArray : NSArray

{

}

+ monthArray;

- (unsigned)count;

- (id)objectAtIndex:(unsigned)index;

@end

#import "MonthArray.h"

@implementation MonthArray

static MonthArray *sharedMonthArray = nil;

static NSString *months[] = { @"January", @"February", @"March",

    @"April", @"May", @"June", @"July", @"August", @"September",

    @"October", @"November", @"December" };

+ monthArray

{

    if (!sharedMonthArray) {

        sharedMonthArray = [[MonthArray alloc] init];

    }

    return sharedMonthArray;

}

- (unsigned)count

{

 return 12;

}

- objectAtIndex:(unsigned)index

{

    if (index >= [self count])

        [NSException raise:NSRangeException format:@"***%s: index

            (%d) beyond bounds (%d)", sel_getName(_cmd), index,

            [self count] - 1];

    else

        return months[index];

}

@end

A Composite Object

By embedding a private cluster object in an object of your own design, you create a composite object. This composite object can rely on the cluster object for its basic functionality, only intercepting messages that the composite object wants to handle in some particular way. This architecture reduces the amount of code you must write and lets you take advantage of the tested code provided by the Foundation Framework. Figure 2-13 depicts this architecture.

The composite object must declare itself to be a subclass of the cluster’s abstract superclass. As a subclass, it must override the superclass’s primitive methods. It can also override derived methods, but this isn’t necessary because the derived methods work through the primitive ones.

The count method of the NSArray class is an example; the intervening object’s implementation of a method it overrides can be as simple as:

- (unsigned)count {

return [embeddedObject count];

}

However, your object could put code for its own purposes in the implementation of any method it overrides.

#import <foundation/foundation.h>

@interface ValidatingArray : NSMutableArray

{

    NSMutableArray *embeddedArray;

}

+ validatingArray;

- init;

- (unsigned)count;

- objectAtIndex:(unsigned)index;

- (void)addObject:object;

- (void)replaceObjectAtIndex:(unsigned)index withObject:object;

- (void)removeLastObject;

- (void)insertObject:object atIndex:(unsigned)index;

- (void)removeObjectAtIndex:(unsigned)index;

@end

#import "ValidatingArray.h"

@implementation ValidatingArray

- init

{

    self = [super init];

    if (self) {

        embeddedArray = [[NSMutableArray allocWithZone:[self zone]] init];

    }

    return self;

}

+ validatingArray

{

    return [[[self alloc] init] autorelease];

}

- (unsigned)count

{

    return [embeddedArray count];

}

- objectAtIndex:(unsigned)index

{

    return [embeddedArray objectAtIndex:index];

}

- (void)addObject:object

{

    if (/* modification is valid */) {

        [embeddedArray addObject:object];

    }

}

- (void)replaceObjectAtIndex:(unsigned)index withObject:object;

{

    if (/* modification is valid */) {

        [embeddedArray replaceObjectAtIndex:index withObject:object];

    }

}

- (void)removeLastObject;

{

    if (/* modification is valid */) {

        [embeddedArray removeLastObject];

    }

}

- (void)insertObject:object atIndex:(unsigned)index;

{

    if (/* modification is valid */) {

        [embeddedArray insertObject:object atIndex:index];

    }

}

- (void)removeObjectAtIndex:(unsigned)index;

{

    if (/* modification is valid */) {

        [embeddedArray removeObjectAtIndex:index];

    }

}