Person *person = [[Person alloc] init];
person.mobileNumber = @"1-555-123-1234";

This is uber nifty, and can save you a load of time and redundant code. However it’s often the case that I want to hide access to certain private member variables, but still expose accessors/mutators to attributes on those private variables. Let’s say mobileNumber is actually an accessor/mutator on a sub-object, let’s call it PhoneBook. Under the hood, this is implemented like so:

@interface Person {
    PhoneBook *phoneBook;
}

@property (nonatomic, rertain) NSString *mobileNumber;
@end

@implementation Person
- (void)setMobileNumber:(NSString *)number {
    phoneBook.mobileNumber = number;
}

- (NSString *)mobileNumber {
    return phoneBook.mobileNumber;
}
@end

This seems far from ideal, when really I just want to pass through the implementation of this accessor/mutator to one of my instance variables. A more clean and hypothetical implementation could look like this:

@interface Person {
    PhoneBook *phoneBook;
}

@property (nonatomic, retain) NSString *mobileNumber;
@end

@implementation Person
@synthesize mobileNumber=phoneNumber.mobileNumber;
@end

NSArray *participants = [archive valueForKey:@"participants"];
NSEnumerator *en = [participants objectEnumerator];
User *user = nil;

while (user = [en nextObject]) {                    
    // do stuff with the user
}

So what’s fascinating about this simple block of code? Let me explain. Lets say archive is a regular NSDictionary object, and participants is an OPTIONAL key/value in this dictionary which could contain an array of Users. How does that affect the rest of our code? Well that means the NSArray participants will be nil. So what happens when you call objectEnumerator on a nil object? An error? Nope! calling a message (any message) on an nil object returns nil. So that means en, our enumerator, becomes nil. Now when we get to our while loop calling nextObject on en will also return nil. Thus the loop terminates gracefully without any error checking code, an no sig-faults from calling our “nil” objects. I’ve just written code that not only performs it’s task but gracefully degrades even under optional conditions.