It's Black Friday, and that means it's time for another Friday Q&A. Today I'm going to talk about the use of accessors in Objective-C init/dealloc methods, a topic suggested by Jon Trainer.

Introduction
There has been a change in the Cocoa community in the past few years, where the use of accessors in init/dealloc is frowned upon, recommend against, and outright considered to be wrong. It is much better, they say, to directly access instance variables instead. In other words, the recommendation is to write code like this:

    - (id)initWithWhatever: (id)whatever
    {
        if((self = [self init]))
        {
            _whatever = [whatever retain];
        }
        return self;
    }
    
    - (void)dealloc
    {
        [_whatever release];
        
        [super dealloc];
    }

    - (id)initWithWhatever: (id)whatever
    {
        if((self = [self init]))
        {
            [self setWhatever: whatever];
        }
        return self;
    }
    
    - (void)dealloc
    {
        [self setWhatever: nil];
        
        [super dealloc];
    }

    - (id)init
    {
        _ivar = [NSArray arrayWithObjects:...];
        return self;
    }

    - (id)init
    {
        [self setIvar: [NSArray arrayWithObjects:...]];
        return self;
    }

Cons of Accessors
The downside to using accessors in this way can be summed up in one short sentence: accessors can have side effects. Sometimes these side effects are undesirable for init/dealloc.

When writing a setter, it needs to behave correctly if you're going to call it from init/dealloc. This means dealing with a partially constructed object.

Worse, if you ever override a setter in a subclass, you need to write it to handle the case where the superclass is using that setter to initialize or destroy its ivars. For example, this bit of innocuous-looking code is potentially dangerous:

    - (void)setSomeObj: (id)obj
    {
        [anotherObj notifySomething];
        [super setSomeObj: obj];
    }
    
    - (void)dealloc
    {
        [anotherObj release];
        [super dealloc];
    }

It's not hard to fix this code to handle the situation gracefully. Simply assign anotherObj = nil after releasing it in dealloc, and everything works again. In general it's not difficult to make sure that your overrides behave properly, but if you're going to use accessors like this then you must remember to, and that is the difficult part.

Key-Value Observing
A topic which is frequently brought up in these discussions is key-value observing, because KVO is a common way for accessors to have side effects. Like other cases, if KVO side effects are triggered when the object is partially initialized or destroyed, and that code isn't written to tolerate such an object, bad things will occur. I personally think that it's mostly a red herring.

The reason it's mostly a red herring is because 99% of the time, KVO is not set up on an object until after it's already fully initialized, and is ceased before an object is destroyed. It is conceivable for KVO to be used such that it activates earlier or terminates later, but it's unlikely in practice.

It's not possible for outside code to do anything with your object until it's fully initialized, unless your initializer itself is passing pointers around to outside objects. And likewise, it's not possible for outside code to keep a KVO reference to your object as it's executing its dealloc method, because it's too late for it to remove it, unless your dealloc triggers something that allows it to do so. Superclass code does execute in these timeframes, but superclass code is extremely unlikely to do anything to cause external objects to observe properties that the superclass itself doesn't even have.

Conclusion
Now you know the pros and cons; should you use accessors in init and dealloc? In my opinion, it can go either way. The advantages aren't generally that great. The downsides are minor. I don't use accessors for the vast majority of my instance variables, but there are certain cases where the advantages become significant because I'm doing something special with an ivar, and in that case I don't hesitate to let the accessors save me some headache.

That's it for this week. Come back next week for another round. If you have a topic you would like to see covered here, send it in! Friday Q&A is driven by your suggestions, and the more I receive, the better topics you get to read about.

Add your thoughts, post a comment:

Spam and off-topic posts will be deleted without notice. Culprits may be publicly humiliated at my sole discretion.