13

In Apple's Programming with Objective-C the section on Encapsulating Data states that:

You Can Define Instance Variables without Properties

It’s best practice to use a property on an object any time you need to keep track of a value or another object.

In other words they are strongly recommending that you use private properties rather than instance variables for any private object state.

I am wondering why this might be the case? I understand that properties have features such as KVO, and attributes (strong, weak ...), but in many cases I do not need these features and an instance variable will work just fine.

Are there any good reasons why instance variables might not be considered best practice?

Community
  • 1
  • 1
ColinE
  • 68,894
  • 15
  • 164
  • 232
  • For my humble opinion it's Apple charm - they don't say "you can", they say "you should" :) – brigadir Dec 24 '13 at 09:46
  • To summarize the discussion in the comments and carefully reading the source text: Apple doesn't say *private variables are bad practice*, they say *properties in general are best practice*. And, it's a general advice targeted at people who are just learning about instance variables. – ilya n. Dec 24 '13 at 09:59
  • 1
    Lots of good general discussion here: http://stackoverflow.com/questions/10432441/when-to-use-instance-variables-and-when-to-use-properties?rq=1 & the specific question about Apple's text I believe is answered already :) – ilya n. Dec 24 '13 at 10:07
  • @ilyan. - thanks for the reference, although the answer is weak "The advice now (for ARC) is, I believe, use properties to declare your external interface, but use direct instance variables where the variable is part of the object's internal state." - I'd love to see a citation for this advice! – ColinE Dec 24 '13 at 10:12
  • To throw something else in, there is a slight performance hit when using properties (being as you're then sending messages, rather than referencing a specific pointer). This is usually completely insignificant, but I have had times where the difference is noticeable (i.e. tightly nested loops, e.g. for image processing). I appreciate there are ways around this, but it's something worth considering. – sammyd Dec 24 '13 at 20:50
  • @sammyd there are some detailed microbenchmarks here http://blog.bignerdranch.com/4005-should-i-use-a-property-or-an-instance-variable/ not that it is relevant in most contexts! – ColinE Dec 24 '13 at 21:15
  • Well, I believe there is a good general agrument in recommending properties for beginners, but then many specific arguments pro and contra for different use cases. I mention tight loops in my answer :) and note didn't we hear something about **premature optimization**, no? – ilya n. Dec 24 '13 at 22:43
  • I like to use properties only because I then have a consistent programming style and have all the property advantages when I need them some day. Second when my code is edited by another programmer she or he will wonder why there are sometimes properties and sometimes iVars. So I prefer consistency. See the book "Clean Code: A Handbook of Agile Software Craftsmanship". As ColinE mentioned the performance impact is neglectibe for most cases. – blackjacx Jan 08 '14 at 12:46

3 Answers3

3

Even though right now your private variable might work as a plain variable, you may decide later that some of properties 'goodies' are useful:

  • observing
  • atomic accessors
  • custom accessors
  • logging on access
  • access from subclasses

If you only access your variables as properties, you don't add much overhead (except in tight cycles) and leave room for reaping any of those benefits described above.

Basically, properties are useful even if you don't ever plan on making them public.

Of course, there are places where using an instance variable is still 'more natural', for example if you reimplement Foundation classes in a class cluster (such as NSArray), it's expected that your implementation is private and performant, so I don't use properties then.

Also, I don't think you should read too much into the advice. To me it reads more like "If you've only learned 5 minutes ago about properties and instance variables, let's start with using properties first".

People who are new to the language can go quite far without knowing what the instance variables are.

ilya n.
  • 18,398
  • 15
  • 71
  • 89
  • 1
    I see your point, but I fundamentally disagree with the concept of using a certain technique because you might need its features later on. This approach can lead to overly complicated software. If I need those features, I use properties. If I do not, I use instance variables. And I am happy to change between the two based on the requirements of a specific situation. Anyhow - thanks for the answer, your input was still greatly appreciated :-) – ColinE Dec 24 '13 at 09:46
  • Well, I describe one argument for using properties; there are balancing arguments against them. – ilya n. Dec 24 '13 at 09:48
  • 2
    @ColinE, the problem with your approach is that it is then very difficult to audit the code for correct usage. You must look at every single ivar access and ask "was I supposed to use an accessor here?" That leads to bugs and difficult to maintain code. Consistency allows easy auditing, and direct ivar usage makes consistency impossible. Since there are many cases where you must use properties, it is best to always use properties. This is Apple's point, and is best practice in ObjC. – Rob Napier Dec 28 '13 at 02:45
1

In other words they are strongly recommending that you use private properties rather than instance variables for any private object state.

Where did you read that they are recommending private properties? I think they mean public variables/properties.

And of course using properties instead of public instance variables has a lots of advantages:

  • encapsulation and custom getters/setters
  • memory management
  • KVO
  • binary compatibility
  • and so on

But in my opinion using private properties in general has no advantages and it's much easier to use private instance variables. The only reason I can imagine is to make custom getters/setters for such variables in future, but I don't think that it's a "best practice".

Dmitry
  • 7,300
  • 6
  • 32
  • 55
  • **It’s best practice `A`... If you do need then `example B`** does imply that Apple recommends pattern `A` over `B` (`B` here being private variables). And note there are times when you *need* them (not only custom setters, but also observing and atomicity, see my answer). Do they have advantages in general? As I say, as a beginner advice, it's a good one. – ilya n. Dec 24 '13 at 09:56
  • "Where did you read that they are recommending **private** properties?" - good point, there is some ambiguity here. I don't think any sane developer would recommend public instance variables! However the phrase "It’s best practice to use a property on an object any time you need to keep track of a value or another object." does seem to imply that any objects state, or association between objects should be defined as a property. It certainly doesn't state that this is a recommendation just for public state. – ColinE Dec 24 '13 at 09:56
  • For what its worth, I feel private properties have little value also. For example, when have you ever need to use KVO for a 'privately owned' object? Or use weak references? – ColinE Dec 24 '13 at 09:58
  • I personally use private properties all the time to provide access to subclasses, and to implement custom checks in setters. I also use instance variables, but never export them, even to subclasses. Didn't see much use for KVO here, indeed :) – ilya n. Dec 24 '13 at 10:04
-1

The point is underlaying storage abstraction. So simple yet very powerful.

Denis Mikhaylov
  • 2,035
  • 21
  • 24