Don’t Use Accessor Methods in Initializer Methods and dealloc

Question

I am doing some reading about the Memory Management and they do not recommend to use accessor methods in initializer method.

Question: why should not we use accessor methods in initializer method?

I am confusing about it.

Answer 1

Here's an example I wrote which demonstrates two things:

• how initialization can be reordered
• how leaks can be introduced

Initializing a property, dot notation

Although the example focuses on initialization, dealloc is susceptible to similar categories of problems. As one specific example: an object may partially resurrect itself in dealloc, and reference count imbalances become a potential danger.

Briefly, you want to focus on correct initialization and cleanup of the data your objects need -- rather than the behavioral concerns/influence of your objects through any subclasses.

---

More reading:

Why myInstance = nil instead of self.myInstance = nil?

Should I refer to self.property in the init method with ARC?

Best way to set a retained property to a newly created object

Answer 2

That is a bit of a religious issue with developers on both sides and the arrival of ARC has further muddied the issue.

A couple of reasons are:

1. The object is not fully initialized and the accessor may depend on a fully initialized object.

2. The accessor may have side effects and again the object is not fully initialized. One common side effect is instantiating an iVar on first use.

These arguments can also apply to using accessors in dealloc (for non-ARC code).

Answer 3

KVC observers monitor the getter and setter methods. Unless you are absolutely certain that no-one will ever observe your property, then you are asking for trouble. Have a defect where an observer is mucking around with a partially dealloc'ed object is very hard to reproduce and nearly impossible to test for.

Answer 4

The main reason behind not using accessor methods in intiailiser methods and dealloc probably stems from Mac OS X development and is probably not so much of an issue on iOS. Mac OS X GUI development involves a useful thing called "bindings" which allows you to bind a control's property to a property of an object, so that when the user updates the control, the "binding" will automatically update the property, and if the program updates the property (via the accessor methods), the "binding" will automatically update the control.

A lot of binding stuff is done with Key-Value Observing (I think). Key-Value Observing is when an object observes changes to properties on other objects. Whenever you use an accessor method to change a property, any object that is observing your object will be notified so that it can take action on the new value of the property. Using accessor methods can trigger any Key-Value Observing notifications when you don't want them to occur, such as during initialisation and deallocation, because any observers of your object will be dealing with only a partially initialised or partially deallocated instance rather than a fully initialised instance.

There is also another main area of concern, and that is when your object is subclassed. When you use the accessor methods to set properties of your object, you will actually be invoking the accessor methods of your subclass (if it implements different accessor methods). This is less likely to be an issue because inheritance in Objective-C development is rare compared to say .NET.