There are several ways to write setters for Objective-C\/Cocoa objects that work. But here are the practices I follow; to the best of my knowledge they produce the safest code.<\/p>\n
When possible, it’s best to write immutable objects<\/a>. Generally they are safer, and easier to optimize, especially when it comes to concurrency.<\/p>\n By definition immutable objects have no setters, so always ask yourself if you really<\/em> need a setter<\/strong>, before you write one, and whenever revisiting code.<\/p>\n I’ve removed many of my setters by making the thing they set an argument to the class’s becomes,<\/p>\n This is less code, and now, It’s not always practical to do without setters. If an object looks like it needs a settable property, it probably does. But in my experience, questioning the assumption that a property needs to be changeable pays off consistently, if infrequently.<\/p>\n This should go without saying, but as long as I’m enumerating best-practices: if you are using Objective-C 2.0 (iPhone or Mac OS X 10.5 & up) you should use The obvious benefits are less code, and setters that are guaranteed to work by the compiler. A less obvious benefit is a clean, abstracted way to expose the state values of an object<\/a>. Also, using properties can simplify you But watch out for the a gotcha if you are using (Note: Some Cocoa programmers strongly dislike the dot-syntax that was introduced with properties and lets you say I covered this in detail here<\/a>. In summary, use When properties are unavailable, this is my “go-to” pattern:<\/p>\n Sometimes I use use This pattern is only two lines of code, and has no conditionals<\/strong>. There is very little that can I can screw up when writing it. It always does the same thing, which simplifies debugging.<\/p>\n Using If the old value is immediately released in the setter then this code will sometimes crash,<\/p>\n If But if If This is the pattern that google recommends.<\/a><\/p>\n \nWhen assigning a new object to a variable, one must first release the old object to avoid a memory leak. There are several “correct” ways to handle this. We’ve chosen the “autorelease then retain” approach because it’s less prone to error. Be aware in tight loops it can fill up the autorelease pool, and may be slightly less efficient, but we feel the tradeoffs are acceptable.<\/p>\n When Again, there are no conditionals in this pattern. There’s no I like naming my temporary old-value But I don’t think it’s necessarily the best choice for doing more to To be honest I’m still evaluating that naming practice. But so far I’ve been happy with it.<\/p>\n This is an old maxim of Computer Science, but it bears repeating.<\/p>\n The most common pattern for a setter feels like premature optimization:<\/p>\n Testing But it also slows every<\/em> call to To know what way is faster, you have to measure real-world conditions. Even if a or<\/p>\n Does that look like code you want to optimize? (Trick question! You don’t know until you test.)<\/p>\n I constantly break Principle 3 by declaring properties in iPhone<\/em> code as I can’t shake the feeling I’m wrong to do this. But it seems more wrong to not follow Apple’s example; they wrote the iPhone OS in the first place.<\/p>\n There isn’t a way to write a setter that works optimally all<\/em> the time, but there is a setter-pattern that works optimally more often then other patterns. With your help I can find it.<\/p>\n-initWith:<\/code> constructor. For example,<\/p>\nCustomWidget *widget = [[CustomWidget alloc] init];\n[widget setController:self];<\/pre>\n
CustomWidget *widget = [[CustomWidget alloc] initWithController:self];<\/pre>\n
widget<\/code> is never in a partially-ready state with no controller.<\/p>\nPrinciple 1: Use
@synthesize<\/code><\/h3>\n@synthesize<\/code>-ed properties<\/a> to implement your setters.<\/strong><\/p>\ndealloc<\/code> method<\/a>.<\/p>\ncopy<\/code>-assignment for an NSMutable<\/code> object<\/a>!<\/p>\nx.foo = 3;<\/code> instead of [x setFoo:3];<\/code>. But, you can use properties without using the dot-syntax<\/strong>. For the record, I think the dot syntax is an improvement. But don’t let a hatred of it it keep you from using properties.)<\/p>\nPrinciple 2: Prefer
copy<\/code> over retain<\/code><\/h3>\ncopy<\/code> over retain<\/code> whenever possible: copy<\/code> is safer<\/strong>, and with most basic Foundation objects, copy<\/code> is just as fast and efficient as retain<\/code>.<\/strong><\/p>\nThe Preferred Pattern<\/h3>\n
\n- (void) setX:(TypeOfX*)newX;\n{\n [memberVariableThatHoldsX autorelease];\n memberVariableThatHoldsX = [newX copy];\n}\n<\/pre>\nretain<\/code>, or very rarely mutableCopy<\/code>, instead of copy<\/code>. But if autorelease<\/code> won’t work, then I use a different pattern. I have a few reasons for writing setters this way.<\/p>\nReason: Less Code<\/h4>\n
Reason:
autorelease<\/code> Defers Destruction<\/h4>\nautorelease<\/code> instead of release<\/code> is just a little bit safer, because it does not immediately destroy the old value.<\/p>\n\nNSString* oldName = [x name];\n[x setName:@\"Alice\"];\nNSLog(@\"%@ has changed their name to Alice\", oldName);\n<\/pre>\n
-setName:<\/code> immediately releasees the value that -name<\/code> returned, oldName<\/code> will be invalid when it’s used in NSLog<\/code>.<\/p>\n-setName:<\/code> autorelease<\/code>-ed the old value instead, this wouldn’t be a problem; oldName<\/code> would still be valid until the current autorelease pool was drained.<\/p>\nReason: Precedent<\/h4>\n
- (void)setFoo:(GMFoo *)aFoo {\n [foo_ autorelease]; \/\/ Won't dealloc if |foo_| == |aFoo|\n foo_ = [aFoo retain]; \n}\n<\/pre>\n<\/blockquote>\nBackup Pattern (No
autorelease<\/code>)<\/h3>\nautorelease<\/code> won’t work, my Plan-B is:<\/p>\n\n- (void) setX:(TypeOfX*)newX;\n{\n id old = memberVariableThatHoldsX;\n memberVariableThatHoldsX = [newX copy];\n [old release];\n}\n<\/pre>\nReason: Simple<\/h4>\n
if(oldX != newX)<\/code> test for me to screw up. (Yes, I have done this. It wasn’t a hard bug to discover and fix, but it was a bug nonetheless.) When I’m debugging a problem, I know<\/em> exactly what setX:<\/code> did to it’s inputs, without having to know what they are.<\/p>\nOn
id old<\/code><\/h4>\nid old<\/code>, because that name & type always<\/em> works, and it’s short. It’s less to type, and less to think about than TypeOfX* oldX<\/code>.<\/p>\nold<\/code> than sending it release<\/code>.<\/p>\nPrinciple 3: Only Optimize After<\/em> You Measure<\/h3>\n
- (void) setX:(TypeOfX*)newX;\n{\n if(newX != memberVariableThatHoldsX){\n [memberVariableThatHoldsX release];\n memberVariableThatHoldsX = [newX copy];\n }\n}\n<\/pre>\nif(newX != memberVariableThatHoldsX)<\/code> can avoid an expensive copy<\/code>.<\/p>\nsetX:<\/code>. if<\/code> statements are more code, that takes time to execute. When the processor guesses wrong<\/a> while loading instructions after the branch, if<\/code>‘s become quite expensive<\/a>.<\/p>\ncopy<\/code> is very<\/em> slow, the conditional approach isn’t necessarily faster, unless there is code that sets a property to it’s current value. Which is kind of silly really. How often do you write code like,<\/p>\n[a setX:x1];\n[a setX:x1]; \/\/just to be sure!<\/pre>\n
[a setX:[a x]];<\/pre>\n
Hypocrisy!<\/h4>\n
nonatomic<\/code>, since it’s the pattern Apple uses in their libraries. I assume Apple has good reason for it; and since I will need to write synchronization-code to safely use their<\/em> libraries, I figure it’s not much more work to reuse the same code to protect access to my objects.<\/p>\nIf you know a better best practice, say so!<\/h3>\n
UPDATE 03-30-2009:<\/h4>\n