I'm rather confused about properties and instance variables in Objective-C.
I'm about half-way through Aaron Hillegass's "Cocoa Programming for Mac OS X" and everything is logical. You would declare a class something like this:
@class Something; @interface MyClass : NSObject { NSString *name; NSArray *items; Something *something; IBOutlet NSTextField *myTextField; } @property (nonatomic, retain) NSString *name; @property (nonatomic, retain) NSArray *items;
Since other objects need to manipulate our name
and items
instance variables, we use @property
/@synthesize
to generate accessors/mutators for them. Within our class, we don't use the accessors/mutators—we just interact with the instance variable directly.
something
is just an instance variable that we're going to use in our class, and since no one else needs to use it, we don't create a pair of accessors and mutators for it.
We need to interact with a text field in our UI, so we declare an IBOutlet
for it, connect it, and we're done.
All very logical.
However, in the iPhone world, things seem to be different. People declare properties for every single instance variable, declare properties for IBOutlets
, and use accessors/mutators to interact with instance variables within the class (e.g. they would write [self setName:@"Test"]
rather than name = @"Test"
).
Why? What is going on? Are these differences iPhone-specific? What are the advantages of declaring properties for all instance variables, declaring properties for IBOutlets
, and using accessors/mutators within your own class?
An instance variable is a variable that exists and holds its value for the life of the object. The memory used for instance variables is allocated when the object is first created (through alloc ), and freed when the object is deallocated.
A property can be backed by an instance variable, but you can also define the getter/setter to do something a bit more dynamic, e.g. you might define a lowerCase property on a string which dynamically creates the result rather than returning the value of some member variable.
Each instance variable lives in memory for the life of the object it is owned by. Variables are properties an object knows about itself. All instances of an object have their own copies of instance variables, even if the value is the same from one object to another.
In the iPhone world, there's no garbage collector available. You'll have to carefully manage memory with reference counting. With that in mind, consider the difference between:
name = @"Test";
and
self.name = @"Test"; // which is equivalent to: [self setName: @"Test"];
If you directly set the instance variable, without prior consideration, you'll lose the reference to the previous value and you can't adjust its retain count (you should have release
d it manually). If you access it through a property, it'll be handled automatically for you, along with incrementing the retain count of the newly assigned object.
The fundamental concept is not iPhone specific but it becomes crucial in an environment without the garbage collector.
Properties are used to generate accessors for instance variables, there's no magic happening.
You can implement the same accessors by hand.
You can find in Aaron Hillegass's book examples of 3 memory management strategies for member variables. They are assign/copy/retain
. You select one of those as required for given variable.
I assume you understand memory management in Objective-c ...
Accessors hide the complexity and differences of memory management for each variable.
For example:
name = @"Test"
is a simple assignment, name
now holds reference to NSString @"Test"
. However you could decide to use copy
or retain
. No matter which version of memory management you chose accessor hides the complexity and you always access the variable with (or similar):
[self setName:@"Test"] [self name]
Now setName:
might use assign/copy or retain
and you don't have to worry about it.
My guess is that iPhone tutorials use properties to make it easier for new developers to jump through memory management (even though it's handy to generate appropriate accessors with properties rather than implement them by hand every time).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With