Re: Best Way to Handle Properties?
Re: Best Way to Handle Properties?
- Subject: Re: Best Way to Handle Properties?
- From: Ken Thomases <email@hidden>
- Date: Wed, 20 Aug 2008 11:25:43 -0500
On Aug 20, 2008, at 8:59 AM, Dave wrote:
On 20 Aug 2008, at 13:30, Ken Thomases wrote:
On Aug 20, 2008, at 6:05 AM, Dave wrote:
This makes memory management awkward. This code is creating an
object using alloc, so it's responsible for releasing it.
However, you're not keeping a pointer to the new string you've
created. You're just passing it to the PersonDetails object and
then forgetting it. So, you can't release it.
Yes, this is what worried me. The set method (setFirstName) stores
the NSString pointer inside itself, and the "reset" method
releases it in this case. The reason I did this is because if I
were to specify "copy" instead "assign" for the property, then
there would be two NSString Objects allocated one here and one
inside the "set" method. I was trying to avoid allocating two
Objects, e.g. the method would look something like this:
-(void) setFirstName:(NSString*)theNewValue
{
if (FirstName != theNewValue)
FirstName = [theNewValue copy];
}
Or am I missing something?
You're engaging in premature optimization. Get it right first,
then worry about performance (after measuring!).
I just took the example from the Objective C manual.
My comment about premature optimization was regarding you trying to
avoid an extra copy. I was suggesting that you shouldn't be concerned
about such things until after 1) you've got things working the right
way and 2) you measure an actual performance problem.
I mean the initializer method should take as arguments all of the
pieces of information required for a Person (or PersonDetails)
object to be valid. Generally, if an object exists (is
successfully allocated and initialized), it should be valid. If it
can't be made valid, then the initializer should fail (return
nil). If there are different possible combinations of information
that could make a valid Person, then that suggests you want to have
several different initializers, each taking different sets of
arguments. If you do, please make sure you understand the notion
of designated initializer and how all of your other initializers
should funnel through that one.
The problem with that there are a *LOT* of properties which is why
the data was being passed in a structure and now being stored in an
object. The initializer would have about 56 arguments, which in my
book is horrible.
Are all 56 properties required for the object to be valid? I wasn't
suggesting that you not use setters after the object is initialized.
I was suggesting that initializing an object should result in a valid
object.
In some cases, it makes sense to design an initializer that takes a
_source_ of information. In that case, the initializer knows how
to extract the information it needs from the source. As you
worried, a bad design of this type might require the class to know
intimate details of several such sources of information, resulting
in close coupling between classes and violations of encapsulation.
However, it's possible to make a fairly general design of this
type. In particular, Cocoa already has one: the NSCoder/NSCoding
mechanism. You might consider using this approach for your
design. See the Archives and Serializations Programming Guide for
Cocoa.
The file format is complex and the sources of data are quite
different, to design and implement a "common" information source
from with the object that holds the data would be very complex and
overkill in this case in my opinion.
Could be. It was just a suggestion.
For what it's worth, I wasn't suggesting that you implement a common
information source. I was suggesting that your various information
sources could each be wrapped in their own NSCoder-derived classes.
That is, they would present a common interface but not necessarily
have common implementations. From what I recall from your original
post, your reader class is already somewhat similar to a keyed
unarchiver.
Cheers,
Ken
_______________________________________________
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