Geek Answers Handbook

When do you not want to use @synthesized instance variables?

In a modern Objective-C environment, you can do something like this:

@interface MyClass : NSObject { } @property NSString *stringProperty; @end @implementation MyClass @synthesize stringProperty; @end

I agree with the modern runtime environment, it not only synthesizes accessors for my property, but also the instance variable itself, so I could say in one of these methods of the class [stringProperty length]; , and this will work just as if I have declared an instance variable.

I started using this in all of my code because, well, this is another thing that I have to write over and over again. And I heard with the clang 2.0 compiler, I can even skip @synthesize (but that's another matter). But I was wondering what are some of the disadvantages of this? When may I need an instance variable in addition to my properties?

I know what sometimes happens when I want to keep a private variable and not provide access to it from outside (but then I usually just declare the property in my private class extension or don’t create a property for it if I don't need accessors for it).

Is there a time when I would not want to do this?

+4
source share
5 answers

One possible reason why it would be wise not to use synthesized instance variables is a bit more painful to debug the current version of Xcode (3.2.5). It seems that they are not displayed in real debugger mode when running code through GDB, the only way to get to them is through the gdb console, for example po [0xOBJ_ADDRESS propertyName] . Not quite as good as a standard, non-synthesized ivar.

Xcode 4 may fix this, but I don't have enough experience to say (and it is still under the NDA).

More info on this SO question: See the value of the synthesized property in the Xcode debugger when there is no backup variable

+4
source

You might want to provide many properties for a single instance variable, for example:

  • to access the angle value in both degrees and radians
  • for access to coordinates in both rectangular and polar systems

In these cases, you do not want to synthesize instance variables (they already exist) or access methods (you want to provide them to perform transformations).

+3
source

Anytime you need to do the conversion (unless someone knows a better way) in the class you need to serialize. For example, if you have a class with a numeric value. You cannot serialize an integer to store it as an NSNumber in a class, but the property is an integer type.

Another example is the code that Apple recommends when working with CoreData. They say that you should create your own class derived from NSManagedObject as a class for a managed object and use a property for each attribute. Then you should use @dynamic instead of @synthesize, and iVar is not needed at all.

+1
source

But I was wondering what are some of the disadvantages of this? When may I need an instance variable in addition to my properties?

Possible reasons:

  • it allows you to change the instance variable in init and dealloc without being disabled by subclass or KVO overrides.
  • the application will compile and run in 32-bit mode on Mac OS X. There are some more Intel Macs that do not support 64-bit.

I'm not sure how important the first moment is. There may be other solutions to problems. The second point is the game, though, if you need to support older Macs.

+1
source

Another reason is to avoid shortcuts to direct access to the variable.

I am trying to follow a personal coding convention: - object variable: prefix with underscore '_xxx' - property: named without underscore 'xxx'

This ensures that I will never inadvertently write something like

 xxx = value;

or

 [xxx someMessage];

I want to always use getter / setter.

 self.xxx = value; [self.xxx someMessage];

This is especially useful when you use lazy init for object variables ...

0
source

More articles:


All Articles