- Cocoa objects are either mutable or immutable.
- You cannot change the encapsulated values of immutable objects; once such an object is created, the value it represents remains the same throughout the object’s life.
- But you can change the encapsulated value of a mutable object at any time.
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 says, 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:
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 drier 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 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 ones that encapsulate collections of discrete values or contain values that stored in buffers.
- 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 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 kinda 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 an NSDictionary object.