If you're going to use properties, good programming practice dictates that you
always go through your accessor methods. The slightly more verbose syntax makes your code more readable by clearly distinguishing and identifying the scope of public properties from instance (which may be private) or local variables. The additional overhead is also negligible unless you're in a tight loop, in which case you can use a local variable inside the loop and accessor methods around it.
Always using accessor methods can help you with debugging. You can monitor a property which is acting strangely by overriding the synthesized accessors, testing for invalid values and breaking as necessary. This may be easier than using watchpoints in gdb for complex cases.
If you always go through accessor methods, your code will be ready for interesting KVC technologies that make Cocoa so powerful, such as KVO, object archiving, and eventually Core Data and Cocoa Bindings (hopefully). If you directly access your properties, you bypass the runtime mechanism for hooking into these technologies.
Quote:
|
Originally Posted by exorcyze
It's true that prefixing with self calls the setter method. But the point is that in cases where no retain/copy/release is being performed in the setter ( IE when you specify assign, readwrite, etc for nonatomic properties ) that the two are functionally performing the same thing behind the scenes.
|
Note that this will not work if you're using KVO, say, to keep your UI in sync with your model objects, even for simple properties such as assigned scalars. This is important because you have no control over who may want to observe a property you've declared, which is public by definition. Being a good citizen means always going through the accessor so any observers can be properly notified. This isn't an issue for code you entirely own, but if you ever plan to release it as part of a framework or collaborate with others, it's best to follow good habits from the start.
