36

I understand that @synthesize window; combined with @property 'auto-creates' your setters and getters, but I'm not sure exactly what happens when you assign a value like

 @synthesize searchBar = _searchBar;

Does this mean that I can simply use _searchBar instead in my methods rather than say self.searchBar ?

Is it to prevent a clash of ivar names for instance with this delegate method:

- (void) searchBar:(UISearchBar *)searchBar textDidChange:(NSString *)searchText

Is it the equivalent of self.searchBar rather than searchBar or are those two identical anyway?

Gazzer
  • 4,524
  • 10
  • 39
  • 49

3 Answers3

32

Your properties almost always have a backing variable. What

@synthesize searchBar = _searchBar;

does is declare that the backing variable for your search bar will be called _searchBar. This allows you to decouple the name of the property from the name of your variable. In fact, if you don't use @synthesize you don't need to have a backing variable at all.

As for why people do this, everyone has different reasons. Personally, I do it to

  1. avoid clashes with variable names and
  2. make it clear when I'm using a local variable and when I'm using an instance variable.
kubi
  • 48,104
  • 19
  • 94
  • 118
  • "...almost always..." is this determined by the compiler or the programmer? Can you provide examples of when the backing-variable does not exist? – mobibob Jul 20 '11 at 16:45
  • 2
    Determined by the programmer. Example of when a backing-varible does not exist is `self.tableview` in a `UITableViewController`. Getting that property returns the same view as returned by `self.view`. – kubi Jul 20 '11 at 21:26
18

The syntax is described in the documentation -- see Property Implementation Directives.

The reason for changing the instance variable name is precisely to discourage direct access. An underscore is used by convention. (Note: Although the Coding Guidelines currently warn against using an underscore, this advice is out-of-date.)

Again per the documentation (see Using Accessor Methods), apart from init and dealloc methods, you should always use accessor methods. You use set accessors to ensure that you manage memory correctly, and that you emit KVO change notifications if appropriate. You use get accessors to ensure that the property is correctly initialised. There are several common places where properties are initialised lazily; if you don't use the accessor, you get nil...

An example of direct access: Using one of the Core Data templates, if you used:

NSFetchRequest *request = ...;
NSError *error = nil;

NSArray *results = [__managedObjectContext executeFetchRequest:request error:&error];

instead of

NSArray *results = [self.managedObjectContext executeFetchRequest:request error:&error];

then -- because the managed object context is created lazily in the accessor method -- you might end up sending a message to nil and getting no results.

mmalc
  • 8,201
  • 3
  • 39
  • 39
  • 1
    Thanks for detailed answer. Can you explain this: "precisely to discourage direct access". Perhaps with a code example of direct access, indirect access. – Gazzer Mar 27 '11 at 09:43
17
@synthesize searchBar = _searchBar;

says to make a getter method named "searchBar" (etc.) for the instance variable _searchBar.

The underscore on the _searchBar variable usually means "Don't access me directly unless you really know what you're doing. Please use the getter and setter methods instead!".

hotpaw2
  • 70,107
  • 14
  • 90
  • 153