Re:
Re:
- Subject: Re:
- From: "Shawn Erickson" <email@hidden>
- Date: Wed, 22 Aug 2007 09:30:10 -0700
On 8/22/07, Daniel Child <email@hidden> wrote:
> Your list of advice brings up host of questions. Specifically, (in
> reference to your points)
>
> #1 (always use accessors)
> Would you recommend using accessors even for primitive instance
> variables (int, BOOL, etc.), where there is no need to retain, copy,
> etc.
The fact that you store them internally as a primitive instance
variable currently doesn't mean that in the future you may store them
a different way. If you provide accessors as the interface to get at
the data then you have more freedom to change your implementation in
the future without affecting client code.
> #3 (when no factory, create as category on the class.)
> I have been creating "constructors" (and I guess you don't call them
> that in Obj-C) using something like:
>
> + myClass {
> MyClass *mc = [[[MyClass alloc] init] autorelease];
> return mc;
> } // other constructors like +myClass:withValue: to follow
>
> Will this pattern be safe? Or is there a better approach.
These are generally called convenience constructors since they give
you a instance of an object that you can use temporarily without
having "ownership" of the object (don't have to manage its life time).
The are safe (if callers follow the memory management contract) and
often are useful. I normally don't add them until I find that client
code can benefit from them.
> #5 - #6 (use immutable objects whenever possible) Why the emphasis on
> immutable objects? Simply because they are more efficient?
They usually will be more efficient when accessed, etc. but obviously
they wont be more efficient if they need to be modified.
The important thing to consider is what you care about when you take
ownership, ask yourself... Do I want the same object state going
forward in time as when I first got the object (if so copy it, if not
retain it). A variant of the prior questions factors in the need for
you to be able to modify it and if you want to modify a local copy or
a shared object (for the former mutableCopy, the later retain).
Also recall that mutable objects are often subclasses of immutable
objects. So you could get passed a mutable object even if you
interface states that you take an immutable object. So often the
safe/wise thing to do is copy what you take ownership of (assuming it
supports copy and immutable/mutable variants). Doing so will ensure
you hold onto what you expect (a copy of an immutable object is often
done using a simple retain so it incurs little overhead to use copy).
> #7 (use [self setThing: nil] in dealloc)
> Kochan had [iVar release] in his dealloc methods. What is the
> advantage of using [self setThing: nil] instead? (7)
Depends... use of an accessor centralizes your memory management for
the ivar in a single spot however accessors can have intentional side
effects (for example triggering a view element to update when the
value changes) and those side effect may not be desired when you are
in dealloc. Personally I don't use accessors in dealloc (at least in
most situations).
> #8 (use a class accessor for class globals etc.)
> ???? I have no idea how to do 8. I expect to need plenty of class-
> related constants. For example, my singleton class (a string parser
> to parse input into syllables) has a list of values against which
> input text is to be checked. I stored those values in an NSSet which
> is one of the instance variables. You are recommending something else?
Again it depends on the intent, desire visibility, and on it being a
constant or variable. Don't have time at the moment to list the
various ways... likely a google search will show some examples.
-Shawn
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >Re: (From: Daniel Child <email@hidden>) |