NSDictionaries vs. custom objects with properties, what's your take?

Question

I'm writing an App that basically uses 5 business entities, A, B C, D and E

• A has some properties and holds a list of B's
• B has some other properties and a list of C's and a list of D's
• C has some other properties and a list of D's and a list of E's
• D has only a few properties
• E has only a few properties

There is no inheritance between any of them. There's no real business logic involved, the objects are created, populated, and then accessed read-only, no further manipulations.

My natural coding style would be to go object oriented and write classes for each of those entities, use NSArrays for the lists, and have the mentioned properties synthesized.

It would make the code readable.

But another approach seems obvious too: only use NSDictionaries and NSArrays, and working with keys/values instead of properties. This seems more efficient, and somehow "closer" to iPhone-style programming to me... but obviously leads to less readable code. Another advantage is there's no additional custom encoding/decoding for serialization required (persisting state to disk, using JSON, ...) So on the paper, it speaks for the latter approach, on the other hand, it still feels somehow awkward NOT to use custom objects...

Is this really just a matter of taste question? Or are there maybe other arguments in favour/against one of the approaches? Is only using Dictionaries better memory/performance-wise? Is it the preferred "Apple Coding Style"? (I'm coming from Java/C#).

Answer 1

It largely depends on whether your objects are just collections of data (key/value pairs) or implement their own functionality.

If they're data I'd say go with NSDictionary, it's a lot less code and as you point out you won't have to write serialization routines for each class.

Answer 2

I don't see much difference between Java/C# and Cocoa in this area. Your question is equivalently applicable to those platforms as well (the same also applies to key-value stores and relational stores).

In an object oriented environment, you have to make a trade-off between the flexibility of the key-value approach for storing data and the structured and object oriented style. I'd go with the key-value approach only when I need the flexibility (e.g. the structure is dynamic and might change by user or not known at compile time). Otherwise, taking that route might get you completely off the OOP conventions and benefits (By the way, this is the important point. Does the hassle of sticking to object oriented principles worth it for that specific circumstance? I think your question reduces to this one and to answer it, you should analyze your specific situation)

Answer 3

Use a hybrid approach. Store the dictionaries the objects are based on, but expose the most-used values as properties that are either filled when the object is initialized from a dictionary, or have the accessors look into the dictionary for values (less efficient).

Also provide a property to get at the dictionary. This way if you need to propagate a new value quickly to a specific area of the code from the dictionary (presumably a new value added by the server) you have that flexibility. Then if callers are making heavy use of a value you can migrate it to be a true property and get the completion and type checking of a property.