7/1/08 11:53 AM, also sprach [EMAIL PROTECTED]: > 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 (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]
