Register FAQ / Rules Forum Spy Search Today's Posts Mark Forums Read
Go Back   MacRumors Forums > Apple Systems and Services > Programming > Mac Programming

Reply
 
Thread Tools Search this Thread Display Modes
Old Mar 5, 2009, 10:20 AM   #1
mdeh
macrumors 6502
 
Join Date: Jan 2009
Advice on good programming practice, please

From Kochan's book, an example ( barebones)

Code:
@interface  AddressCard:NSObj......   <NSCopying>

{

NSSTring * name;
}
@property ( copy, nonatomic)  NSString *name;
In the addresscard's implementation

Code:
-(void) encodeWithCoder: (NSCoder *) encoder

{

[encoder encodeObject: name forKey........]

From advice I have received here before, I am assuming, perhaps as I incorrectly understood the advice that invoking "name" in the encodeWithCoder method, **directly** uses name, as opposed to using the self.name invocation ( and therefore the accessor).

Now, if this is true, what is the best practice here. When would I use "self" vs what what I have written above?

Thanks as always
mdeh is offline   0 Reply With Quote
Old Mar 5, 2009, 06:53 PM   #2
North Bronson
macrumors 6502
 
Join Date: Oct 2007
Location: Los Angeles
In your case, I would find myself using [self name] to access your NSString.

One cool thing about using your getter method is that it you have a little control over how you can load your instance variable.

If I have an NSArray called myVeryLargeArray, I can write a getter method that loads this array if someone asks for it (if nobody ever asks for it, it just remains nil). This is a lazier approach than loading it somewhere like my init method.

You wouldn't want to use a getter method *inside* of your getter method. If you follow the advice to load resources with your getters, you can also go ahead and access directly in the dealloc method of your class (since you are releasing the object anyway, why load it with a getter method?).

Another thing is that it can remove a layer of ambiguity in your methods. If your style is to *always* use getter methods when you can, then if you see a line like:

[encoder encodeObject: name forKey. . . ]

then it can help to make things a little clearer that name is *not* an instance variable of the class itself. If your method is several pages long, it helps to get the point across -- at least for me.
__________________
North Bronson Software
North Bronson is offline   0 Reply With Quote
Old Mar 5, 2009, 08:28 PM   #3
mdeh
Thread Starter
macrumors 6502
 
Join Date: Jan 2009


Thank you for all your insights. Much appreciated.
mdeh is offline   0 Reply With Quote

Reply
MacRumors Forums > Apple Systems and Services > Programming > Mac Programming

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Similar Threads
thread Thread Starter Forum Replies Last Post
Advice on learning programming harlanjmichael Mac Programming 10 Mar 13, 2014 01:02 PM
Good practice to share the disk space for MacOS and PD VM(WIn8)? oldguru MacBook Pro 1 Mar 14, 2013 05:28 AM
GLKit programming reference - something good KnightWRX iPhone/iPad Programming 5 Aug 17, 2012 12:45 PM
Good resources for Cocoa programming kaworu1986 Mac Programming 9 Jul 23, 2012 02:22 PM

Forum Jump

All times are GMT -5. The time now is 06:58 PM.

Mac Rumors | Mac | iPhone | iPhone Game Reviews | iPhone Apps

Mobile Version | Fixed | Fluid | Fluid HD
Copyright 2002-2013, MacRumors.com, LLC