Is it "bad" to use @properties for private variables just for the memory management benefits?

Question

Is it bad to create @properties for private variables just for the memory management benefits?

It seems messy and wrong to have public facing @properties for many private variables.

(Mainly, I am releasing private ivars during low memory conditions using the respective "event" methods.)

Example: I usually do this to release a private ivar:

[name release]; name = nil;

But with @properties, I can do this:

self.name = nil;

Later in my code, will do this, hence the need to set to nil:

if( !name)
    name = [[NSString alloc] initWithFormat:@"Hi %@",inputName];

Answer 1

For public properties I don't think Apple recommends it, because sometimes setting a property to nil can have side effects other than just releasing the variable (KVO notifications, or a custom setter method that does something else).

As for private properties, I'm not too sure. Using a property will only save you a couple of key strokes while coding, but you're also making it slightly more complex and fragile. I favour readability and maintainability over convenience to write, because you'll save time in the long run.

Answer 2

Properties exist for your convenience. If you don't want other people to use properties that exist in your classes, just don't document them.

Answer 3

An alternative is to keep the property private. You can use the following code (in your .m file) to make the property only accessible within your class:

#import "MyClass.h"

@interface MyClass ()
    @property (retain) NSString* privateString; 
@end

@implementation MyClass

    @synthesize privateString;
    // Your code here

@end

Now you've got the ease of a property, but other classes still can't access it, even if they import your .h file!