Re: Struct, Object, or Dictionary?
Re: Struct, Object, or Dictionary?
- Subject: Re: Struct, Object, or Dictionary?
- From: Keary Suska <email@hidden>
- Date: Tue, 01 Jul 2008 12:30:47 -0600
- Thread-topic: Struct, Object, or Dictionary?
7/1/08 11:53 AM, also sprach email@hidden:
> I have been debating using one method over another for a while now, and I
> would like to know what the Cocoa way of doing things is. I need to group a
> set of data together to use as one entity. In one program I was representing
> a puzzle as four strings and a BOOL. My first thought would be to represent
> these as a struct. However, the strings within the struct would have to be
> memory managed, so I guess that would mean writing my own methods to retain,
> release, autorelease, etc. the struct. My second option in this case is to
> declare an object that would contain all of those data members as ivars, and
> the memory management would be taken care of. However, it doesn't seem right
> to make an object that only has data and no methods. My third option would
> be to store all of the data in dictionary pairs. This doesn't seem as
> reliable as the last methods though, because there is no guarantee that the
> dictionary would contain all the necessary name/value pairs. What is the
> "correct" way to do this in Cocoa?
I don't know that a "Cocoa" way exists for this kind of thing, per se, but I
would look at it in a more OOP and "why reinvent the wheel" approach. That
would call for an NSDictionary. In short, I would start with generic,
existing classes first.
As a general rule, when I have a situation where I need a group of data
items to be kept together and passed around, I would consider these in
order:
1. If all data values are Objective-C types or string literals, then a
struct is probably appropriate;
2. If *all* (or most) data values are objects, and no special handling (such
as validation) is needed, then an NSDictionary is probably appropriate;
3. At this point, I am usually looking at a custom object, but only if I
expect to have a number of them. If there is only one, there is likely
something wrong with my design, and I need to refactor.
4. Lastly, and I have it here because of its non-trivial implementation, is
to consider Core data. This is most appropriate with object graphs of some
complexity. You get a lot "for free" (without code), including basic (but
flexible) validation and undo support.
HTH,
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
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