{"id":286,"date":"2009-03-31T13:51:51","date_gmt":"2009-03-31T18:51:51","guid":{"rendered":"http:\/\/vgable.com\/blog\/2009\/03\/31\/how-to-write-cocoa-object-getters\/"},"modified":"2009-04-03T12:58:55","modified_gmt":"2009-04-03T17:58:55","slug":"how-to-write-cocoa-object-getters","status":"publish","type":"post","link":"https:\/\/vgable.com\/blog\/2009\/03\/31\/how-to-write-cocoa-object-getters\/","title":{"rendered":"How To Write Cocoa Object Getters"},"content":{"rendered":"

Setters are more straightforward than getters<\/a>, because you don’t need<\/em> to worry about memory management. <\/p>\n

The best practice is to let the compiler write getters for you, by using Declared Properties<\/a>.<\/p>\n

But when I have to implement a getter manually, I prefer the (to my knowledge) safest pattern,<\/p>\n

- (TypeOfX*) x;\n{\n  return [[x retain] autorelease];\n}<\/pre>\n
Note that by convention in Objective-C, a getter for the variable jabberwocky<\/code> is simply called jabberwocky<\/code>, not<\/em> getJabberwocky<\/code>.<\/p>\n
Why retain<\/code> Then autorelease<\/code><\/h3>\n
Basically return [[x retain] autorelease];<\/code> guarantees<\/em> that what the getter returns will be valid for as long as any local objects in the code that called the the getter.<\/p>\n
Consider,<\/p>\n
NSString* oldName = [person name];\n[person setName:@\"Alice\"];\nNSLog(@\"%@ has changed their name to Alice\", oldName);<\/pre>\n
If -setName:<\/code> immediately release<\/code>es the value that -name<\/code> returned, oldName<\/code> will be invalid when it’s used in NSLog<\/code>.  But if the implementation of [x name]<\/code> used retain\/autorelease<\/code>, then oldName<\/code> would still be valid, because it would not be destroyed until the autorelease pool around the NSLog<\/code> was drained.<\/p>\n
Also, autorelease pools are per thread<\/em>; different threads have different autorelease pools that are drained at different times. retain\/autorelease<\/code> makes sure the object is on the calling thread’s pool.<\/p>\n
If this cursory explanation isn’t enough, read Seth Willitis’ detailed explanation of retain\/autorelease<\/code><\/a>. I’m not going to explain it further here, because he’s done such a through job of it.<\/p>\n
Ugly<\/h3>\n
return [[x retain] autorelease];<\/code> is more complicated, and harder to understand then a simple return x;<\/code>.  But sometimes that ugliness is necessary, and the best place to hide it is in a one-line getter method. It’s self documenting. And once you understand Cocoa memory management, it’s entirely clear what the method does. For me, the tiny readability cost is worth the safety guarantee<\/strong>.<\/p>\n
Big<\/h3>\n
return [[x retain] autorelease];<\/code> increases peak memory pressure, because it can defer dealloc<\/code>-ing unused objects  until a few autorelease pools are drained. Honestly I’ve never measured memory usage, and found this to be a significant problem.  It certainly could be, especially if the thing being returned is a large picture or chunk of data. But in my experience, it’s nothing to worry about for getters that return typical objects, unless there are measurements saying otherwise.<\/p>\n
Slow<\/h3>\n
return [[x retain] autorelease];<\/code> is obviously slower then just return x;<\/code>. But I doubt that optimizing an O(1) getter is going to make a significant difference to your application’s performance — especially compared to other things you could spend that time optimizing.  So until I have data telling me otherwise, I don’t worry about adding an the extra method calls.<\/p>\n
This is a Good Rule to Break<\/h3>\n
As I mentioned before, getters don’t need<\/em> to worry about memory management. It could be argued that the return [[x retain] autorelease];<\/code> pattern is a premature optimization<\/em> of theoretical<\/em> safety at the expense of concrete<\/em> performance<\/strong>.<\/p>\n
Good programmers try to avoid premature optimization; so perhaps I’m wrong to follow this “safer” pattern. But until I have data showing otherwise, I like to do the safest thing.<\/p>\n
How do you write getters, and why<\/em>?<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"
Setters are more straightforward than getters, because you don’t need to worry about memory management. The best practice is to let the compiler write getters for you, by using Declared Properties. But when I have to implement a getter manually, I prefer the (to my knowledge) safest pattern, – (TypeOfX*) x; {   return [[x retain] […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,203,3,5,4,13],"tags":[376,241,616,279,224,174,375],"class_list":["post-286","post","type-post","status-publish","format-standard","hentry","category-cocoa","category-iphone","category-macosx","category-objective-c","category-programming","category-sample-code","tag-autorelease","tag-best-practices","tag-iphone","tag-mac-os-x","tag-memory-management","tag-nsobject","tag-retain"],"_links":{"self":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/286","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/comments?post=286"}],"version-history":[{"count":0,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/286\/revisions"}],"wp:attachment":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/media?parent=286"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/categories?post=286"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/tags?post=286"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}