3

With ARC, every pointer assignment does a retain by default. In that light, in noatomic cases, why do I even need to declare properties?

How are these two any different?

//Property
@interface I1 : NSObject 
@property (nonatomic, strong) NSString* str;
@end

I1 *obj1 = ...;
obj1.str = [[NSString alloc] init...];

//Only member variable
@interface I2 : NSObject { 
@public
    NSString* str;
}
@end
I2 *obj2 = ...;
obj2->str = [[NSString alloc] init...];
Rayfleck
  • 12,116
  • 8
  • 48
  • 74
RajV
  • 6,860
  • 8
  • 44
  • 62
  • This question sounds a LOT like [iOS: must every iVar really be property?](http://stackoverflow.com/q/5031230/590956). Other related question: [Why would you use an ivar?](http://stackoverflow.com/q/9086736/590956) – Sam Feb 17 '12 at 17:31

6 Answers6

2

Properties is a part of the Objective Orientation Programming. This is encapsulation! How they can not be used?! Always use properties to encapsulate your data.

beryllium
  • 29,669
  • 15
  • 106
  • 125
  • If an ivar is declared in the `@implementation` there is encapsulation so there is room for discussion in this case. – zaph Feb 17 '12 at 17:04
  • In nonatomic case described above, property hardly does any encapsulation. Prior to ARC, sure, there was value in have property do retain/release. – RajV Feb 17 '12 at 17:06
2

@property/@synthesize pairs autogenerate getters and setters, and thus affording encapsulation.

Of course, often this encapsulation might not be needed right now, but maybe in the future you'll decide to add some lazy initialization to the iVar, or want to post a notification when the content of the iVar changes. It's good habit to always use properties and synthesized or hand-written accessors, and the cost is negligible. Why would you not use them?

(If you are concerned that @property/@synthesize is too much boilerplate, and you have a Mac Dev account, have a look at the Beta forum.)

fzwo
  • 9,842
  • 3
  • 37
  • 57
  • I think the argument made here about a possible benefit from property in future is valid one. But, my question was purely rooted in the present. As for the question of why I would not use property is a false one. Any action must be supported by reason. Just because an action has no positive or negative effect doesn't mean one should just blindly do it. – RajV Feb 17 '12 at 17:36
  • 1
    @RajV One of the aspects of good code is maintainability, so if you want to argue about purely the present, the question becomes academic. *In practice*, accessors are the better option because they lead to better maintainability without costing anything in the present. One should just make a habit of using them just for this reason, IMHO (with the possible exceptions of private iVars and stuff that is *really and demonstrably* performance-critical). – fzwo Feb 17 '12 at 17:55
  • @fzwo What may be to much is accessing ivars via properties (self.ivar vs ivar) in the case that the ivar is declared in the `@implementation`, thus local to the single file. In such a case later changing to a property is local to the one file and class. Note, I am not arguing one way or the other. – zaph Feb 17 '12 at 18:08
2

Memory management is not the only advantage of using properties.

Two in particular that come to mind for me is:

  1. KVO (without having to manually call willChangeValueForKey: and didChangeValueForKey: - see Manual Change Notification)
  2. Ability to write custom logic for a setter and getter as well as write subclass customizations for the setter and getter.

bbum wrote a great response to this in iOS: must every iVar really be property?

Community
  • 1
  • 1
Sam
  • 26,946
  • 12
  • 75
  • 101
0

I would think properties are still used for automatically generating accessors and mutators where @public isn't used.

James Webster
  • 31,873
  • 11
  • 70
  • 114
  • In the nonatomic case presented here, the generated accessor/mutator must be so trivial to the point of being unnecessary. That is the core question. Do we even need property? – RajV Feb 17 '12 at 17:09
  • There is KVO to be considered. – zaph Feb 17 '12 at 17:34
0

In the interface use @property because that is advertising public access. If you do not want to actually make it a public put the @property declaration in a class extension or the ivar declaration in the @implementation in the .m file.

zaph
  • 111,848
  • 21
  • 189
  • 228
0

In objective-c, @property is just a abbreviation for standard setter and/or getter of a variable in the class. So no matter your ARC option is on or off, you can make your choice at your convenience.

shadowglen
  • 66
  • 1