Re: Best Way to Handle Properties?
Re: Best Way to Handle Properties?
- Subject: Re: Best Way to Handle Properties?
- From: Dave <email@hidden>
- Date: Wed, 20 Aug 2008 12:05:30 +0100
Hi All,
Thanks a lot all who replied!
I understand the point about using lowercase characters to start the
member names, e.g. "FirstName" --> "firstName", I am in the process
of changing this now.
I have a couple more questions:
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?
There are a few approaches to fixing this. First, you can use a
local variable to hold a pointer to the new object. Then, after
passing it to setFirstName: you can release it. Second, you can
use alloc/init/autorelease where you currently use alloc/init.
How do I specify autorelease?
Third, you can use a convenience method which creates a string for
you but doesn't leave you responsible for releasing it, such as
+stringWithCharacters:length:.
What is the difference between -stringWithCharacters:length: and
+stringWithCharacters:length: ? Looking at the documentation it's not
obvious (to me anyway) what the difference is.
The more normal way to do things is not to use objects as just dumb
containers. That is, it's not typical to reset an object and reuse
it with completely unrelated content.
The way this part of the application is structured is that there are
two main objects. One to handle reading from the file and returning
data in a "common" format and one to write the data into a database
that is used later in the application. The reader fills in
"PersonDetails" and the writer accepts a "PersonDetails" object and
writes it into the database. The data can actually come from more
that one place (exist in different formats), there will be other
objects that return data in a "common" format. (In this case the
"common" format is taken care of by the "PersonDetails" object). The
reason it's called "PersonDetails" and not just "Person" is because
that's what it was called in the Original code and I didn't take much
notice of the name.
In this case I am initializing a database from scratch, so I need to
iterate through a file and read all the "PersonDetails" one at a
time. Other places in the code may want to read and retain number
"PersonDetails" in order to do compares. Also a query may be sent to
the database object which would return an array of "PersonDetails"
objects.
So, I guess the best way to do it would be to Allocate and Free a new
"PersonDetails" object each time through the loop, or have the
"ReadPersonString" method allocate and return a "PersonDetails"
object. The "Reader" Object could then keep track of the
"PersonDetails" object and free it on subsequent calls to
"ReadPersonString" and when the file is closed.
Your mindset is reflected in the fact that you've named your class
"PersonDetails" rather than, say, "Person". You're not conceiving
of an object with its own identity and responsibilities. You're
just thinking of it as a record or structure for holding some
related data together for a brief time. If that's what you need,
then go for it, but you needn't bother replacing working C code
with an Objective-C class.
The reason I changed it from a C Structure to a Objective C Class is
because someone else on this told me that was the best thing to do,
and also, it's much better to implement the strings as NSString's so
I can use the other cool OS defined methods and so I'd have the
allocation problem anyway.
If you do want to redesign in a more object-oriented fashion, then
you should probably initialize a Person object with its most
salient details at the time of its creation. For example, does it
make sense to ever have a person without a name? If not, then it
shouldn't be possible to create one that way. Similarly, it
doesn't make sense to reset a Person to have no name.
Firstly in the real code there is a "PersonDataValid" flag so I can
tell if it's a good "Person" or not, secondly, unless I put a whole
load of logic in the "PersonDetails" object and/or have it know about
all the reader objects, it can't initialize a "salient" object. Or do
you mean something else?
When you're done with a given Person object, you release it. If
you need a new one, you allocate and initialize a new one.
Ok, I think this is covered above. One more question. If I were to
release a "PersonDetails" object, would the NSString's be released?
If not, do I have to implement my own release method?
Lastly, if you need to do something with/to a Person, you should
most likely tell the Person object to do it. This is just a guess
based on what you've shown above, but I suspect you haven't given
your PersonDetails class much smarts about behavior. You probably
just have a bunch of code which queries PersonDetails objects for
their properties and then does all the work externally to the
PersonDetails class. A good guideline to follow is "Tell, Don't
Ask" <http://www.pragprog.com/articles/tell-dont-ask> (although
it's not a hard-and-fast rule, and shouldn't be taken to extremes).
Yes and No! This is not much intelligence needed in this case, for
instance I always want the FirstName returned as is. However there is
some logic in the "PersonDetails" record, for instance, when dates
are returned they are expanded into a number of different formats
(like Internet Time) and some of the other fields are stored as
integers but returned as floats.
Thanks a lot for you help it's greatly appreciated.
All the Best
Dave
_______________________________________________
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