9

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];
bentford
  • 33,038
  • 7
  • 61
  • 57

3 Answers3

23

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!

andyvn22
  • 14,696
  • 1
  • 52
  • 74
  • This is great, but it seems like a hack. I'm not sure I'm going to do this in my code, but at least I know there is an alternative to what I'm doing now. Thank you!! – bentford Sep 11 '09 at 01:20
  • 13
    Its not a hack, it is an explicit form of Category called an Extension. . "It is common for a class to have a publicly declared API and to then have additional API declared privately for use solely by the class or the framework within which the class resides" – Peter N Lewis Sep 11 '09 at 02:03
  • 5
    It is absolutely not a hack and is 100% in line with why class extensions were added to the language in the first place. Embrace this pattern with gusto. – bbum Sep 11 '09 at 06:26
  • Got it. I will start using this then. – bentford Sep 11 '09 at 22:28
  • You now have the benefit now that calls to privateString will now cause a compiler warning. However if you ignore them and call from another class [myClassInstance privateString] the program will respond to the selector and will not trigger an error. – jpswain Jan 16 '12 at 00:25
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.

NSResponder
  • 16,861
  • 7
  • 32
  • 46
0

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.

Tom Dalling
  • 23,305
  • 6
  • 62
  • 80
  • Quote from apple documentation in UIViewController Class reference for method - (void)viewDidUnload: "The preferred way to relinquish ownership of any object (including those in outlets) is to use the corresponding accessor method to set the value of the object to nil" – bentford Sep 13 '09 at 10:53
  • I looked around to find the original reason why I thought it was bad (because I forgot), and I found this: http://stackoverflow.com/questions/192721/why-shouldnt-i-use-obective-c-2-0-accessors-in-init-dealloc . It seems that it's only a concern in init or dealloc. – Tom Dalling Sep 13 '09 at 12:33