What are the advantages of use accessors to instances of IB elements?

Question

Usually, when we have to link an interface element to a field of a class, we use the keyword 'IBOutlet' to inform the pre-copiler:

@interface MyController : NSObject {
    IBOutlet NSWindow *theWindow;
}

and in the implementation we use directly the pointer theWindow to call methods of the class NSWindow!

But what are the advantages of tell to the pre-compiler to create some accessors to the object that is pointed by "theWindow" and manage the object through the accessors?

Example:

@interface MyController : NSObject {
   NSWindow *theWindow;
}
@property(retain) IBOutlet NSWindow *theWindow;


@implementation MyController

@synthesize theWindow;

@end

Does the use of the second solution (for all the pointers to interface's elements) slows the performances of the application?

When is it a good practice to use the second way instead of the first?

Thank you!

Answer 1

Well in general I don't retain the properties, and the only way I ever even expose Outlets is if something needs to access an element from the outside, and this is generally a bad sign for your design anyway.

I've not tried it but I'd be tempted to only synthesis the read portion, and I'd probably only use it in places where atomic access where important. Some portions of AppKit aren't always threadsafe.

Answer 2

The time an accessor takes is completely imperceptible. Even if you ran this code millions of times, all the IB machinery would positively dwarf it.

If these variables are only set at that time and never accessed outside the class, accessors might be unnecessary.

Answer 3

Bryan is correct in that you only need to expose UI element properties if access to them is needed from another instance or another class entirely. It is usually a sign of an architectural design problem but not always.

To answer the last two questions:

Does the use of the second solution (for all the pointers to interface's elements) slows the performances of the application?

No. No more than adding a method called -doSomethingReallyComplicated slows the application if that method is never called. It can slow launch having a bunch of unused code (thereby making the binary larger for no reason) and most certainly slows compile time, but it won't impact the application's runtime performance.

When is it a good practice to use the second way instead of the first?

As Bryan said, you expose a UI element as a property (via @synthesize or a hand-coded accessor) when you need to access it from outside a given instance of that class. Again, the need to do this is usually a sign of a design problem.

Answer 4

When a nib is being unarchived, if an accessor exists to set a given outlet, then the unarchiver will use it. If there is no accessor, then the ivar will be set directly using the Obj-C runtime functions to find it by name.

The accessor will be faster, since you'll avoid all the slogging through the runtime to find the ivar in question. That being said, unless you're going to be loading that nib over and over, the difference will be negligible.

The main reason why you would want an accessor for an outlet is the same as for any other ivar or property you want to publish. It's a handy way to make sure that memory management is covered properly.