3

Working on a maintenance project, I am struggling with lot of messy code. In the current assignment, I found that the previous developer has defined property (and synthesize) for each and every iVar and IBOutlet of the class.

As per my understanding, I was used to declare properly of only those variable, which I intended to use outside of that class. And most of the time, I need not to declare property (and synthesize, of course) for any of the IBOutlet.

Can I have any Answer or Document on "When to declaring property and synthesize is needed (or essential)" ?

EDIT:

After reading the Post which Dr.Kameleon Pointed, another Question comes to my mind: What loopholes can be there in code, If I declare each and every iVar as a Propery and Synthesize them? Can I go that way?
viral
  • 4,168
  • 5
  • 43
  • 68
  • [http://stackoverflow.com/questions/3394206/when-do-you-have-to-use-property-and-synthesize-in-the-iphone-sdk][1] check this link. [1]: http://stackoverflow.com/questions/3394206/when-do-you-have-to-use-property-and-synthesize-in-the-iphone-sdk – Rama Rao Apr 12 '12 at 06:27
  • @RamaRao: I really don't think, It answers my question. It explains what the properties are and understanding of the same. I understood it properly. But, My questions is when I can have them and when I can simply ignore declaring them. Hope you are getting my point. – viral Apr 12 '12 at 06:30
  • @i4Apple Have a look at this one : http://stackoverflow.com/questions/5031230/ios-must-every-ivar-really-be-property – Dr.Kameleon Apr 12 '12 at 06:33
  • 1
    @Dr.Kameleon: I edited my post after reading the post you pointed. Thanks for it. – viral Apr 12 '12 at 06:55
  • 1
    @i4Apple You're welcome, my friend! Now, as for your last question I think you've run into someone like that "previous developer"... lol Yep, I (usually) do synthesize almost all my ivars, especially in my most critical projects (hint: I'm a Mac & and NOT iPhone developer). Why? Simply because it's the most fuss-free approach in terms of memory handling + it makes KVO-compliance really smooth. And anyway, I haven't actually observed any real benefits from NOT having properties. (speed gain? hmm... not really; or at least not noticeable...). Just my .2 cents... :-) – Dr.Kameleon Apr 12 '12 at 07:05

2 Answers2

1

There is no as such rule about when to use property and when to use ivar. Using both have their own advantage-

Using ivar-

  1. using ivar provide small performance benefit.
  2. User has to do memory management manually by reference counting

Using Property-

  1. this ensures KVO compliance code.
  2. By using property, memory management is taken by Accessors.

You can checkout following topic for more insight information - http://cocoawithlove.com/2010/03/dynamic-ivars-solving-fragile-base.html

In my opinion, i always prefer to use property as it has lot of benefit over ivars.

rishi
  • 11,779
  • 4
  • 40
  • 59
  • There must be some case, where defining iVar as property does't make any sense. That's what I want to get clear idea about. Any Idea? – viral Apr 12 '12 at 08:31
  • There are always situations where it's not strictly necessary to wrap your ivars in properties. But I think it will be difficult to dream up a situation wherein you *must* not or *should* not do so. It is the use of the property at runtime which potentially degrades performance, but merely providing the property does not. Really, the biggest performance hit you will face when writing the properties is the time you spend typing the code. – QED Apr 14 '12 at 19:23
1

I think in general it's hard to argue that having an extra property or two is all that bad. That being said, including lots and lots of properties and variables can clutter things up and make the code difficult to understand and maintain. And you don't really need an IBOutlet for every frazmabob in your view. So if you're looking to trim the fat a bit, just get rid of anything you don't need to manipulate at runtime. It sounds simple because it is - the only reason to include a variable/property is if you anticipate using it at runtime.

As for presenting properties to the outside world, you're right, it is a primary concept of OO programming to hide things when they don't need to be presented. This is very important if you are part of a team and you don't want others mucking with your data. So go for it - clean up that code and make life easier for yourself and others down the road.

QED
  • 9,803
  • 7
  • 50
  • 87