So in some of the codes I see, they access an objects ivar directly instead of using accessors . What are the advantages of using them instead of accessors?
So how would this
thing = object->ivar
differ from this?
thing = object.ivar
Thanks.
First let me say, I totally loathe the Objective-C dot notation. It sacrifices understandability for brevity and that is a bad thing. In fact, the other two answers here both show evidence of the kind of confusion dot notation introduces.
Having got the rant out of the way, I'll now try to answer the question.
Under the hood, Objective-C objects are implemented as pointers to C structs. This is why
obj->ivar
sometimes works. Given that it's a C struct
(*obj).ivar
should also work exactly as you would expect for C. Having said that, you can make ivars private or protected, in which case using the above outside a scope where they are visible will cause a compiler error.
The dot operator when applied to an Objective-C object (which is a pointer don't forget) has a totally different meaning. It's syntactic sugar for sending an accessor message to the object meaning that:
foo = obj.property;
obj.property = foo;
is identical in effect to
foo = [obj property];
[obj setProperty: foo];
That is all there is to dot notation. If you go through your code changing all instances of the first form to instances of the second form, you have done everything the compiler does wrt dot notation.
In particular
you do not need a declared #property to use dot notation. You can declare the set and get accessors in the traditional way as Objective C methods, although it is definitely best practice to use #property declarations for things that are logically properties.
you do not need a backing instance variable. There's no reason why your getters and setters can't calculate values.
Given the above, the major difference between obj->ivar and obj.ivar is that the former modifies the ivar directly and latter invokes an accessor, this means that the latter can do any memory management stuff needed (retains, releases, copies etc) and can also invoke key value observing.
This is one thing with a huge difference between c/c++ and objective-c.
In C/C++ the . accesses the variable directly and the -> accesses the variable if it's a pointer to the variable, so basically it is the same.
In Objective-C the . is a shortcut to access the property using the setter and getter function and it is always using those functions. You can't access ivars with it if there is no property with that name.
Some say it's "dirty" to allow direct access to the variables. If more people work on the code it's "cleaner" to use accessors because it might be easier to debug where variables are changed since you can always break in the setter.
You can even do "bad" things with it, like:
NSArray *array = [NSArray alloc] init];
int count = array.count;
array.release;
this will technically work, because the array.release is a shortcut for [array release] but it is bad style to use . for other things then properties.
The advantage of properties is that they call methods that work with your ivars, in stead of calling the ivars directly, so you can do things like this:
-(void)setFrame:(CGRect)frame
{
if([self frameIsValid:frame])
{
if(self.flipsFrames)
{
frame.size = CGSizeMake(frame.size.height,frame.size.width);
}
[super setFrame:frame];
[delegate viewSubclass:self ChangedFrameTo:frame];
}
}
Four advantages shown here are:
The possibility to override
The possibility to check a given value
The possibility to alter a given value (use with caution)
A way to react to calls
Another advantage:
-(NSInteger) amountOfMinutes
{
return amountOfSeconds * 60;
}
You can use 1 ivar for multiple properties, saving memory and preventing/reducing redundancy, while keeping useful different formats.
There's not really an advantage to using ivars, except when you don't want to use a property so your class is more encapsulated. That does not make it impossible to reach, but it makes it clear it isn't supposed to be reached.
All ivars are private. There is no way to access them directly from outside the object. Therefore, both of your code samples are equivalent, in ObjC terms.
When you call object.ivar, what you are really doing is calling object's ivar selector. This may be either a getter method that you wrote yourself, or more likely, a synthesized getter method that you created with #synthesize.
thing, however, is an ivar. Your code would be calling the ivar selector on object and assigning the result directly to your instance's thing ivar.
If you had instead written it as self.thing = object.ivar, then you would be using your instance's setter method to assign to thing.
Some of the advantages of using accessors (specifically, synthesized properties) in ObjC are KVO/KVC compliance; better concurrency support; access control (readonly, readwrite); as well as all of the advantages that accessors give you in any other OO language.
Related
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Setters and Getters (Noobie) - iPhone SDK
I am a beginner here. I have just started learning iOS for the last two months and I do not have any programming background. (Little bit of Java though). Can anyone please explain what is getter and setter in Objective C? What is the use of them? Why do we use #property and #synthesize?
Getter is a method which gets called every time you access (read value from) a property (declared with #property). Whatever that method returns is considered that property's value:
#property int someNumber;
...
- (int)someNumber {
return 42;
}
...
NSLog("value = %d", anObject.someNumber); // prints "value = 42"
Setter is a method which gets called every time property value is changed.
- (void)setSomeNumber: (int)newValue { // By naming convention, setter for `someValue` should
// be called `setSomeValue`. This is important!
NSLog("someValue has been assigned a new value: %d", newValue);
}
...
anObject.someNumber = 19; // prints "someValue has been assigned a new value: 19"
Usually it doesn't make much sense to just return the same value from getter and print new value in setter. To actually store something you have to declare an instance variable (ivar) in your class:
#interface SomeClass : NSObject {
int _someNumber;
}
and make accessors (the collective name for getters and setters) to store/retrieve it's value:
- (int)someNumber {
return _someNumber;
}
- (void)setSomeNumber:(int)newValue {
_someNumber = newValue;
}
...
SomeClass *anObject = [[SomeClass alloc]init];
anObject.someNumber = 15;
NSLog(#"It's %d", anObject.someNumber); // prints "It's 15"
Okay, now that property behaves just like the usual variable. What's the point in writing all that code?
First, from now on you can add some extra code to the accessors, which will get executed each time the property is accessed or changed. There are multiple reasons for doing that, for example I may want to do some kind of hidden calculations, or updating my object's state, caching stuff etc.
Second, there are cool mechanisms called Key-Value Coding (KVC) and Key-Value Observing (KVO) in Cocoa. They depend on properties. You can read about them in the Developer Library: KVC Programming Guide and KVO Programming Guide. Those are advanced topics though.
Last, in Objective C there is no static allocation for objects. All the objects are dynamically allocated (reason). If you want to keep your object pointers in instance variables (as opposed to properties) you will have to do all the memory management manually every time you assign new value to your ivar (not true when Automatic Reference Counting is on). Using properties you could put some memory management code in the accessors and make your life easier.
I don't believe this explanation will make much sense to someone who is not familiar with Objective C memory management, so, either read some real docs/tutorials on it, or just use properties (instead of instance variables) until you learn all the details one way or another. Personally, I don't like the second option, but it's up to you.
You can use #synthesize to make the compiler generate basic accessors and underlying instance variables for you automatically. Instead of the code above (-(int)someNumber and -(void)setSomeNumber:) you could just write
#synthesize someNumber = _someNumber; // = _someNumbers tells compiler
// to name the instance variable `_someNumber`.
// You could replace it with = `_somethingElse`, of
// course, but that's an ill idea.
This single line generates int _someNumber variable, someNumber getter and setSomeNumber setter for you. If you want the accessors to do anything more complex than just store/retrieve the value from some instance variable, you will have to write them yourself.
Hope all this makes any sense.
"Getters" and "setters" are used to control changes to a variable (field).
A "setter", is most often used in object-oriented programming, in keeping with the principle of encapsulation. According to this principle, member variables of a class are made private to hide and protect them from other code, and can only be modified by a public member function, which takes the desired new value as a parameter, optionally validates it, and modifies the private member variable.
Often a "setter" is accompanied by a "getter" (also known as an accessor), which returns the value of the private member variable.
Getter/Setter methods may also be used in non-object-oriented environments. In this case, a reference to the variable to be modified is passed to the method, along with the new value. In this scenario, the compiler cannot restrict code from bypassing the getter/setter methods and changing the variable directly. The onus falls to the developers to ensure the variable is only modified through the these methods and not modified directly.
In programming languages that support them, properties offer a convenient alternative without giving up the utility of encapsulation.
Property "getters" and "setters" in most any object-oriented language provide an "external" or user interface around private members of instances of your classes. Some OO critics will refer to them as "syntactic sugar," but what it boils down to is that consumers of your classes will use these interfaces that you control programmatically rather than accessing the actual private member(s) themselves. This way, you can (for example) protect a private variable from receiving an invalid or out-of-range value, or make a property read-only by providing only a getter but no setter. Even more interesting is the idea that getters and setters may wrap properties that aren't natively retained in your class, but might (for example) be computed based on other instance members.
Getters and setters surely aren't unique to Objective-C; if you continue programming in other OO languages, you'll find flavors of them in C#, Java, and others.
Good luck.
When I have my own init method with synthesized properties as such:
#property (copy, nonatomic) NSString *bookName;
#property (strong, nonatomic) NSMutableArray *book;
When I want to initialize with my own custom initializer I am shown to write it like this:
-(id) initWithName: (NSString *)name
{
self = [super init]
if (self) {
bookName = [NSString stringWithString: name];
book = [NSMutableArray array];
}
return self;
}
Now I want to clarify something. I know why it uses the stringWithString method, because instead of just passing the address to the passed in string it'll create a new object so that it owns the string itself. Could I not also just write it like so:
self.bookName = name;
Doing this should use the synthesized method and actually create a new object right? Basically both accomplish the same thing. I ask because there are methods else where that show doing it both ways so I just want to make sure there are no other issues that could crop up with using one way or the other. They both appear to do the same thing in different ways (using the synthesized method vs directly modifying the class variable but creating a new object in memory for it).
I'll also point out that this is in an ARC environment.
(Note that I am assuming the above is ARC code; otherwise it is incorrect.)
You should almost always use accessors to access your ivars (even in ARC). However, there is some controversy about whether init should use accessors or directly access its ivars. I have switched sides in this controversy, but it's not an obvious decision IMO.
The primary argument for not allowing init to use accessors is that it is possible that a future (unknown) subclass might create side-effects in the accessor. You generally don't want side effects happening during your init. For instance, you probably don't want to post change notifications when you're setting something to its initial value, and it is possible that your object is in an "undefined state" and would be dangerous to read at this point.
That said, and while this argument did finally sway me, I have never once encountered this situation on numerous projects of various sizes with several teams. I have many times encountered developers failing to retain when setting their ivars in init (as you have done above, and which would crash if it is not ARC). This is why for a long time I recommended using accessors even in init. But in theory it does create a danger, particularly if you are a closed-source framework writer (i.e. Apple). And so, for my own code I now avoid accessors in init. If I were working with a more junior teams on older retain/release code, I would probably still have them use accessors in init. It's just avoided so many crashes in my experience.
It is not controversial that you should avoid calling accessors in dealloc, however. This definitely can lead to bizarre side-effects in the middle of destroying your object.
You are correct, since bookName is declared as copy, assigning self.bookName would make a copy of the string passed in. I am not certain that copying would go through exactly the same code path as the [NSString stringWithString: name], but it would achieve the same purpose of creating a copy of the original string, shielding you from unexpected consequences of users passing in a mutable object and mutating its value behind your back.
Because the declared property is copy then yes, they are doing the same thing.
Many times however, it is a strong and then there would be a difference between the two methods so the first method would be the "correct" way of doing it.
I understand that one version directly accesses the instance variable and the other calls it's accessor method.
If self.classVariable = sandwich;
&
If classVariable = sandwich;
do the same thing.
Can someone explain the point of the extra typing?
In Objective-C, self.property is property access, not direct instance variable access. It is syntatic sugar for [self property] or [self setProperty:], and thus has the semantics of a message. Modern Objective-C runtime can synthesize a backing instance variable (of the same name as the property), but you may back a property with an instance variable with a different name or none at all. In other words,
self.property = foo;
id bar = property
and
property = foo;
id bar = property;
are not at all the same thing.
It's generally a bad idea to mix direct and property access (with the exception that you should be accessing ivars directly in -init and -dealloc methods) because you will easily run afoul of memory management rules.
The extra typing is to protect the code from future changes, in case a variable is named (in scope) equal to the class member.
It is also considered good practice (in some circles) to include Self when referring to members in the class to be unambiguously clear where it comes from which in some ways helps quicken comprehension of the code.
For Objective-C specifically, there is another difference as noted here http://answers.oreilly.com/topic/1193-calling-self-object-rather-than-calling-the-object-directly-in-objective-c/
The SELF.X notation goes through the accessors generated by the #synthesize directive, whereas X directly bypasses them.
If you go through the accessor you can set breakpoints there. Handy sometimes. Also things like retain/copy properties won't work if you don't go through the accessor.
I have searched many questions on ObjC accessors and synthesized accessors to no avail. This question is more of a "help me settle an issue" question; I don't expect one answer, but I'm rather looking for experts to weigh in on the argument.
In a Cocoa Touch class, I would write some code like this (where soundEffects is a synthesized NSArray property):
id foo = [self.soundEffects objectAtIndex:1];
A colleague asked me to explain why the above is any better than this line:
id foo = [soundEffects objectAtIndex:1];
Well, functionally, it's no different.
My arguments for the former are as follows:
self.soundEffects tells every other coder working on the code that this is an iVar, not a locally scoped variable.
If we ever needed to, we could put custom logic in the soundEffects getter accessor.
For no concrete reason, it "feels" like the right thing to do after working in Obj-C for a year.
He accepts arguments #1 and #2 as valid, but also gives the counterpoint:
Isn't this just code bloat?
Shouldn't a class be allowed to talk to its own iVars directly without having to call a method (the getter) on itself?
Any takers?
I have personally settled on using an underscore prefix for ivars, and this kind of synthesize
#synthesize name = _name;
That way I don't mix them up. The major issue with not using self is that this code
_name = ...
is very different from
self.name = ...
When the #property uses the retain option. The first does not retain the object, and the second calls the synthesized setter that retains.
The only time it makes a big difference is with assigning, so I tend to use self. all of the time so I make sure I do it on assigns.
Your point 1 is not quite right: self.soundEffects is not an ivar, although it may happen to give you something which is -- as it does in the case of your synthesized NSArray, at the moment.
This in turn implies that your point 2 is the crux of the matter -- if you route all access through the accessor, then everything is nicely encapsulated and you're free to modify the implementation later without having to worry about side effects.
It's also good practice for when you use the mutator, so you maintain consistent memory management.
For the most part, I'd say it's advisable to route through self.property for everything that is a property, and restrict direct ivar access to things which are strictly internal. However, I'll admit that in some cases -- especially for things that don't use retain/copy semantics -- it can be more of a style preference.
using something like self.variable = nil makes the variable go through its setter and therefore gets memory managed for free. if you just use variable = nil for instance in a dealloc method, it will cause a leak since it is not actually going through the synthesized setter for the variable and decreasing the retain count. See this post memory leak with self.
For this reason, it is advisable (i believe) to always use self. when dealing with instance variables that you own as far as memory management is concerned.
self.soundEffects sets/gets the instance variable through the setter/getter, and hence if we want to do some custom operations when their value changes, that logic can go in their getter/setter.
Also as per ios 6, the ivar corresponding to
#property (nonatomic)NSArray *propertyName;
will be _propertyName
so i guess you cant use id foo = [soundEffects objectAtIndex:1]; anymore.Not sure though.Instead you should use id foo = soundEffects[1];
When is self needed for class properties? For example:
self.MyProperty = #"hi there";
vs
MyProperty = #"hi there";
MyProperty is an NSString set as (nonatomic, copy). Is there any difference in memory management for the above two?
What about when there is no property and the variable MyProperty is declared in the header file? Is a property needed if it is never referenced outside of the class? Does it make a difference to memory management?
Yes, there is a difference for both memory and performance.
MyProperty = #"hi there";
This is considered a direct assignment. There is practically no memory or performance impact. Of course, that's not to say it's best practice - that's a different question :)
#property(nonatomic, copy) NSString *MyProperty;
// ...
self.MyProperty = #"hi there";
This statement has a significant impact on memory and performance. This is essentially equivalent to:
-(void)setMyProperty(NSString *)newValue {
if (MyProperty != newValue) {
[MyProperty release];
MyProperty = [newValue copy];
}
}
The old value is released and the new value is copied into MyProperty. This is acceptable and especially typical when dealing with strings when the string your assigning is mutable (ie, it could change later).
If, as in your example, you're simply assigning a static string (#"hi there"), there is nothing wrong with directly assigning the string value; it's more efficient however the difference in performance is trivial.
You can declare a property with #property as retain, copy, or assign (default is assign). You can then generate "accessor" (getter/setter) methods by using #synthesize. Here is what the setter methods look like that are generated when you do so:
// #property(nonatomic, assign)
-(void)setMyProperty(NSString *)newValue {
MyProperty = newValue;
}
// #property(nonatomic, retain)
-(void)setMyProperty(NSString *)newValue {
if (property != newValue) {
[property release];
property = [newValue retain];
}
// #property(nonatomic, copy)
-(void)setMyProperty(NSString *)newValue {
if (property != newValue) {
[property release];
property = [newValue copy];
}
}
More information on ObjectiveC Declared Properties.
"You can use the #synthesize and #dynamic directives in #implementation blocks to trigger specific compiler actions. Note that neither is required for any given #property declaration.
Important: If you do not specify either #synthesize or #dynamic for a particular property, you must provide a getter and setter (or just a getter in the case of a readonly property) method implementation for that property."
In other words, if you declare a property but don't synthesize the property, you won't be able to use [self MyProperty] or self.MyProperty unless you define 'MyProperty' and 'setMyProperty' methods. If you don't declare a property then you simply have an instance variable.
Note: #dynamic doesn't generate the accessors. It's really used if you're dynamically (ie, magically) resolving accessor methods via loading code or dynamic method resolution.
The difference is that
self.MyProperty = #"hi there"
is dot-notation call that will call the generated accessor, which will handle the retain counts correctly (equivalent to [self setMyProperty:#"hi there"]), whereas
MyProperty = #"hi there"
is a direct assignment to your member variable, which doesn't release the old value, retain the new one, or do anything else your accessor does (e.g., if you have a custom setter that does extra work).
So yes, there is a big difference in memory management and in behavior in general between the two. The latter form is almost always wrong, unless you know specifically why you are doing it and that you are handling the retain counts correctly yourself.
If you use automatic Key-Value Observing (or any Cocoa technology that builds on it - like bindings, ...), it is also important use the setter. The observer would not receive any notification if you assign to the ivar.
If you bind "MyProperty" to a NSTextfield and you change your "MyProperty" ivar via code, the bound textfield would still display the old value as it did not receive any change notification.
To access a variable, there is often no need to use the dot notation. Thus, in code generated by the XCode templates, you will see things like:
[flipsideViewController viewWillAppear:YES];
There is no need to write self.flipsideViewController here, because the accessor method typically does nothing except handing you the variable.
So a good rule of thumb is to use dot notation when you are setting a variable (absolutely necessary unless you want to do your own retaining and releasing), but not when you're accessing it:
self.aString = #"Text text text";
NSLog (aString); // No need for self.aString here
NSString* tmpString = aString; // Here neither
When you're using non-object types, like int or float or many others, you can get away with not using the dot notation/setter method. In these cases, there is nothing to retain, so the setter method will do little apart from just assigning the value.
However, synthesized getters and setters do more than just retaining and releasing. As others have mentioned, they are also the engine that keeps the KVO system running. Thus, you should use the proper setters even on ints, floats and the rest.
What about the accessors then? In more advanced contexts, a class might respond to a request for a variable's value even when the variable doesn't exist. To quote the exalted Objective-C manual, classes might provide "method implementations directly or at runtime using other mechanisms [than simple accessor methods] such as dynamic loading of code or dynamic method resolution."
(One way of implementing this sort of on-the-fly response to messages is by overriding NSObject methods like methodSignatureForSelector: and forwardInvocation: .)
For this reason, using properly declared interfaces (whether synthesized or not) is always a good idea when you're working on something big. But it's completely ok to access ivars directly, as long as you set them using the proper API.
(Note: I'm not a Cocoa guru, so corrections are more than welcome.)
For the second part of the question, property definition is not needed, it is a help to us . The #synthesize directive on property generates accessor methods for properties so we don't have to do it manually, and because:
This code instructs the compiler to
generate, or synthesize, the accessor
methods. The compiler will generate
the accessor methods using
well-tested, fast algorithms that are
ready for multi-core and
multi-threaded environments, including
locking variables in setter methods.
Not only does using properties reduce
the amount of code that you have to
write, it replaces that code with the
best possible accessors for today's
modern multi-core systems. Later, if
you need to provide an alternative
implementation for a property
accessor, you can simply add the
appropriate code to your class.
http://developer.apple.com/leopard/overview/objectivec2.html
The nonatomic will avoid use of locking when accessing variables, if you don't specify anything then default is atomic. Locking is useful on multithreaded systems. The copy specifies what code should be generated for accessors, copy will copy the object, retain will retain new object and release old one, assign is good for simple variables like int to just plain assign values.
So when you define your property as you did above (nonatomic,copy) and then use self.MyProperty = #"Hey" you're actually calling generated accessor that will make a copy of the new variable as opposed to just assigning it. You can override accessor and add checking to it.
Because of the above I would say that defining property has benefits even when the variable is not used outside of the class.
I believe to access properties you should use self.MyProperty instead of just MyProperty but I can't point you to explanation why.
Might be something to do with the fact that compiler will generate from
self.MyProperty = #"Hey";
this:
[self setMyProperty: #"Hey"];
But I'm only speculating here.
Whether you call self.MyProperty or MyProperty it should not affect memory management (I would still prefer the first - self.MyProperty).
See Objective-C 2.0 Overview for some high level description from Apple.
As a supplement to the other answers, try to think of it this way:
self.MyProperty = #"hi there";
or
[self setMyProperty:#"hi there"];
(which are equivalent) both call a method, whereas
MyProperty = #"hi there";
Simply sets a variable.
This is an old question, though it used to be "When do I write [self setMyProperty:#"hi there"]?" (Note that self.MyProperty = #"hi there" is exactly equivalent to this.)
The answer I've always heard (and which makes good sense) is always use the accessor; never write MyProperty = #"hi there". There are several reasons:
Memory management is handled for you; you don't have to worry about proper retaining/releasing/copying.
It's easier to modify your code in the future; if at some point you realize that changing MyProperty needs to have a particular side effect, you can add to the setter method without finding every time you set MyProperty.
If you ever have problems with MyProperty, it's easy to add logging code to the setter (or even getter) to find out every time it's changed (or even accessed).
Summary: it's safest and most flexible to always use [self setMyProperty:#"hi there"] or self.MyProperty = #"hi there", and never use MyProperty = #"hi there".
Still not clear on when to use the accessors and when to do direct assignment on ivars ? I have seen lot of Apple examples which directly access the ivars. So using properties for all ivars seems pedantic overkill.
It seems only significant ivars which need to be around longer and are accessed outside tend to use the properties.
Would appreciate some Cocoa gurus to step in and clarify.