On 20 Aug 2008, at 17:25, Ken Thomases wrote:
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.
Ok, I see what you mean, and in general I agree, although sometimes
you may as well do optimization straight off. The reason I did it
like this in that case is that I copied and pasted one template for
all 56 odd properties, I didn't want to have to edit them all again
later on.
The copy operation here, copies that data from one string to a newly
allocated string, right?
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.
Yes, all 56 properties are required for the object to be valid, so in
the initializer I set the NSString pointers to nil, zeroize the
integers and set the dataValid flag to FALSE. Then the reader makes
calls to the setters to set each field. Once all fields have been
set, it sets the dataValid flag to TRUE.
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.
Ok, I'll get this working first and then take a look at NSCoder etc.
Cheers,
Ken
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
