when you create a variable in class you need to create 2 methods set and get to assign values and retrieve it.
but you dont have to do this with properties, it is already done for you... so why not just make everything a property rather than regular variables ?
I tried to look through some documentation but could not find anything.
Your question isn't quite accurate. There are two scenarios you describe:
Declared properties:
@interface Person : NSObject
{
NSString *_name;
}
@property NSString *name;
@end
Explicitly declaring accessor methods:
@interface Person : NSObject
{
NSString *_name;
}
- (NSString *)name;
- (void)setName:(NSString *)name;
@end
In the first case (@properties), the compiler will synthesize accessor method implementations for you. In the second case (manually defined accessor methods), you'll have to implement them yourself. Also, in the first case, assuming you're deploying to a system with the modern Objective-C runtime (ie. iOS or 64-bit OS X), you don't have to explicitly declare an instance variable to back the property, as the compiler will do that for you too. (In the "old days" or when deploying to 32-bit Mac OS X, even for @properties you have to manually declare an instance variable and include an @synthesize statement in the implementation).
Otherwise, these are functionally equivalent. Using @property is essentially just a convenient, less verbose way to declare accessor methods for a property, and to tell the compiler that you want them implemented for you.
These days, there's almost never a reason to declare accessor methods manually instead of using a declared @property. Defining custom accessor methods is another story. It's often the case that you want to do something more complex than simply setting/returning an instance variable in your accessor methods, and in that case, you have to define your own accessor methods. You can do that even if the property was declared using @property.
As far as using a bare instance variable instead of using accessor methods at all goes, that's a whole other topic. There is a small performance benefit to directly accessing an ivar. It's also possible to make them truly private. (@properties can be made "private" by putting them in the implementation, but it's still possible to call the accessor methods at runtime if one is determined to do so). That said, in my opinion, it's usually better to use accessor methods instead of ever doing direct ivar access.
*: Declared @properties also allow you to specify memory management and atomicity options in the declaration. These same options are changeable using manually declared/defined accessor methods, but are controlled by the implementation rather than the declaration. (And in the case of making access atomic can be fairly complicated). This is another advantage of @properties. Lastly, @properties can be introspected using Objective-C runtime functions. This is quite an advanced topic, and doesn't matter for the vast majority of Objective-C programs and programmers.
