Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What exactly does @synthesize do?

People also ask

What does @synthesize do in Objective C?

@synthesize tells the compiler to take care of the accessor methods creation i.e it will generate the methods based on property description. It will also generate an instance variable to be used which you can specify as above, as a convention it starts with _(underscore)+propertyName.

What does it mean to synthesizing?

Definition of synthesize transitive verb. 1 : to combine or produce by synthesis. 2 : to make a synthesis of. 3 : to produce (something, such as music) by an electronic synthesizer.

What is the ability to synthesize?

“Synthesis” is the ability to combine parts of a whole in new and different ways. It requires students to think flexibly, determine alternatives, and find new ways to accomplish a given task.

What are some examples of synthesize?

It's simply a matter of making connections or putting things together. We synthesize information naturally to help others see the connections between things. For example, when you report to a friend the things that several other friends have said about a song or movie, you are engaging in synthesis.


In your example, mapView1 is an instance variable (ivar), a piece of memory storage that belongs to an instance of the class defined in example.h and example.m. mapView is the name of a property. Properties are attributes of an object that can be read or set using the dot notation: myObject.mapView. A property doesn't have to be based on an ivar, but most properties are. The @propertydeclaration simply tells the world that there is a property called mapView.

@synthesize mapView = mapView1;

This line tells the compiler to create a setter and getter for mapView, and that they should use the ivar called mapView1. Without the = mapView1 part, the compiler would assume that the property and ivar have the same name. (In this case, that would produce a compiler error, since there is no ivar called mapView.)

The result of this @synthesize statement is similar to if you had added this code yourself:

-(MKMapView *)mapView
{
   return mapView1;
}

-(void)setMapView:(MKMapView *)newMapView
{
  if (newMapView != mapView1)
  {
    [mapView1 release];
    mapView1 = [newMapView retain];
  }
}

If you do add that code to the class yourself, you can replace the @synthesize statement with

@dynamic mapView;

The main thing is to have a very clear conceptual distinction between ivars and properties. They are really two very different concepts.


@synthesize creates a getter and a setter for the variable.

This lets you specify some attributes for your variables and when you @synthesize that property to the variable you generate the getter and setter for the variable.

The property name can be the same as the variable name. Sometimes people want it to be different so as to use it in init or dealloc or when the parameter is passed with the same variable's name.


From the documentation:

You use the @synthesize keyword to tell the compiler that it should synthesize the setter and/or getter methods for the property if you do not supply them within the @implementation block.


As I just run into this problem when editing legacy code I want to make additional notes to the existing answers one needs to be aware of.

Even with a newer compiler version it sometimes does make a difference if you omit @synthesize propertyName or not.

In the case you declare an instance variable without underscore while still synthesizing it, such as:

Header:

@interface SomeClass : NSObject {
   int someInt;
}
@property int someInt;
@end

Implementation:

@implementation SomeClass
@synthesize someInt;
@end

self.someInt will access the same variable as someInt. Not using a leading underscore for ivars does not follow the naming conventions but I just came into a situation where I had to read and modify such code.

But if you now think "Hey, @synthesize is not important any more as we use a newer compiler" you are wrong! Your class then will result in having two ivars, namely someInt plus an autogenerated _someInt variable. Thus self.someInt and someInt will not address the same variables any more. If you don't expect such behavior as I did this might get you some headache to find out.