Hopeless Geek

The problem I had when I was starting out with Cocoa so many years ago was finding the answer to “Why?” rather than “How?” questions. There’s a lot of code out there these days and a lot of people writing code on educated guessed gleaned from reading that code.

So I’m going to make a long read a short one and explain the perfect Cocoa object. Once you have this down, memory management just comes along for free, as does KVC/KVO and mnemonic code.

The Foo Class

Let’s start off with the end result, shall we?

Foo.h

Foo.m

Methods

I’ll presume you know Obj-C at this point, otherwise this would get tedious. So let’s look at the init method and see what’s going on there.

init

First, init is expected to return an object that’s ready to go or return nil if there was a problem. If super’s init returned nil then it would also set self to nil as well. So, we call super’s init and then check self for nil to see if there was an error. Either way, we return the success of super’s init since we have no real way of failing at this point.

If we do succeed, then we give every instance variable (“ivar”) a value so that when we go to access them we don’t crash. Crashing’s bad.

If we do succeed then we set any ivar to its default value if that default value is non-zero. Cocoa’s default alloc method pre-sets all ivars to a zero value (which means nil for objects, consequently) so you don’t have to worry about uninitialized ivars. (Thanks Jeff.)

bar/setBar

In Key-Value Coding you must set your getters and setters (aka accessors and mutators) to property and setProperty. Case matters. So here we have an ivar of _bar. It has an underbar in front so that some enterprising subclasser doesn’t try and pull a object->bar on us and start messing around with things behind the scenes. The underbar is a “Leave me alone.” sign.

So, bar is an object (an NSString, to be precise). Objects come with a memory management contract. It’s not that hard, really. Here, we’re creating and accepting, so we’re getting both ends of the memory management contract.

A summary of that contract:

1. If you changed an object’s retain count, you are responsible for putting it back when you’re done. (Also known as: Anything you create with alloc, new, copy, or keep with retain must have a matching release or autorelease in your code when you’re done with it.)
2. If you did not increase an object’s retain count, don’t be concerned with it. Leave it alone.
3. Any result of a method must be valid at least until the end of the event loop.
4. If you want something to last beyond the end of the event loop, it’s up to you to call retain and keep it somewhere and then release it when you’re done with it.

That’s my summary and interpretation, at least. Apple has the official rules posted.

bar

This is fairly simple to look at, but has one feature that’s not quite obvious. Really, it’s just returning the ivar of a different name. However, notice that it has a retain and autorelease wrapper around it. Why would it have that? Rule #3.

Suppose that you’re a client of this class. You write some code that grabs bar and then starts through a long method with the value you got back. At some point, you set bar to something else. The setBar method will release the ivar and then set the ivar to something else. Anyone that has a reference to the original bar value will be left with a dead pointer because release is instant (if the retain count is zero, which is the worst-case scenario we’re considering here).

This will be a pain in the ass to track down because code elsewhere will crash, not this code. So, to solve that you have to fulfill the memory contract and ensure that anything you give back to the world is valid for the remainder of the current event loop. Since the autorelease pool is flushed at the end of the event loop, you up the retain count by one with a retain and then mark it with autorelease to have that removed at the end of the event loop. Any code that retrieves it will be able to hold onto it for the current event loop — longer still if it retains it and keeps it somewhere.

setBar

As per the memory contract, if we want to hold on to something then we have to retain or copy it and stuff it somewhere. So in this setter we release the old value and set the ivar to the new value and retain it. Simple.

Why is there an if statement in there? At first glance, it’s a needless optimization that says “if these are actually the same object, don’t bother.” Ehh, close. If we’re replacing an ivar with the same object, it’s actually a little tricky.

Suppose we lack that if statement and we have a string with a retain count of 1 in the ivar _bar. Suppose also that we are told to set bar to the same value, as with: [barObj setBar:[barObj bar]]. Or, worse, we use the following inside the class: [barObj setBar:_bar]. What happens?

Well, we release _bar. If the getter is not honoring the memory contract then that invalidates newValue and setting _bar to newValue will result in a crash. Whoops.

Now, if our getter is following the memory contract then that’s not a problem; it’ll be around for the rest of the event loop. However, there are many ways of making a getter and depending on the one you choose, you may not be able to rely on that behavior. Some other getter ideas:

• return _bar;
• return [[_bar copy] autorelease];
• return [[_bar retain] autorelease];

That first one would break this mightily. So, we check for equality before moving on. It’s not always strictly required, but it’s defensive coding and you should get in the habit of doing it. All objects obtained from other methods or classes are considered volatile and should be treated with care if you start to change their retain count.

One last feature of this method is the KVO pair will/didChangeValueforKey. This tells any observers that this object is changing and lets them do anything as a result. Always use this. Always use this in Core Data projects, for it doesn’t do the Right Thing™. However, in standard projects, Apple may be taking care of you here. (Thanks Brian.)

Either way, always make sure this works in your project. You may want to observe your code in the future, or you may want to use bindings (which relies on this heavily), or other code may want to attach to methods on your code that return an object and follow that. If you return a useful object whose getter is speedy, then notify observers when it’s changed.

dealloc

Along the same lines as init, we have to make sure that everything is cleaned up when we leave, so any ivar that could possibly have a retained object must be cleared. Some people choose to manually send release to each ivar and then set it to nil. Frankly, that’s wasteful. We already have setter and getter methods that will do this for us, so use them. Not only does it save you code, but it makes a lot more sense visually.

Just like the first thing you did in init was to call super’s init, the last thing you’ll do in dealloc is call super’s dealloc. You must not call it before you’re done. It’ll kick the floor out from underneath you. Clean up after yourself and then tell super to do the same.

[entry autorelease];

Well, I hope it was useful. If there’s anything wrong with the above, and I’m sure that someone has a different way of thinking, feel free to discuss it below.