18

The question is quite simple: When I create a new API or Service Class should I create a custom class for the objects that are being passed around or should I just stick to an NSDictionary which simply holds the data in a key-value-style format.

Obviously there are pros and cons but where do you guys think is the threshold of using one over the other?

NSDictionary:

+ No dependencies
+ Very Flexible
+ Commonly used
+ Build-in support for NSCoding
- Structure not defined -> Runtime errors

A custom Object:

+ Structure defined
+ Property-style accessors: myObject.someProperty - Can result in a rel. big number of classes for nested objects

Update: Included remarks from jbat100

Community
  • 1
  • 1
Besi
  • 22,579
  • 24
  • 131
  • 223
  • 1
    It depends on your preferences. For example, I always have a business layer logic (BLL) and usually make custom objects. – beryllium Nov 21 '11 at 09:52

3 Answers3

11

I usually have a set of domain models, which fit better with the MVC approach of iPhone development. Having specific objects also enables you to enforce type-safety a lot easier and also reduces complexity in the long run. If you have NSDictionaries containing NSArrays and more NSDictionaries etc etc to represent your object graph, it can very quickly become unmanageable.

Simon Lee
  • 22,304
  • 4
  • 41
  • 45
9

It really depends how much you expect your data model to change. Dealing with changes once you have a custom class based data model can be tricky especially when you have archives (NSCoding stuff) with different versions of the model (in already shipped versions of your app), you must be very careful to ensure backwards compatibility and avoid nasty run time surprises. In that respect NSDictionary based models are, as you say more flexible. However they do not allow all the customized checks and behaviour that custom classes do. Also custom classes make the data model more explicit for coders unfamiliar with the code, from my experience, developers often get sloppy (especially when inexperienced) when dealing with NSDictionary based models which can quickly result in an incomprehensible mess, so if you go down that route, document well and be disciplined!

jbat100
  • 16,757
  • 4
  • 45
  • 70
  • Thanks for mentioning the point about NSCoding I was not aware of that situation. I added this to the list of pro's and con's – Besi Nov 21 '11 at 12:47
4

If you need readonly access and do not need methods, you can do following:

@interface NSDictionary (MyClassCategory)
-(NSString*) someField;
@end

@implementation NSDictionary (MyClassCategory)
-(NSString*) someField {
    return [self objectForKey:@"someField"];
}
@end

typedef NSDictionary MyClass;

And use it:

 MyClass* myClass = ...;
    NSString* value = [myClass someField];
Aliaksandr Andrashuk
  • 967
  • 6
  • 8