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];

}