Alternatives to planned NSDictionary subclass that is singleton

Question

I have successfully created a NSDictionary subclass, a singleton which is intended to hold a set of clues and answers. I was seeing some odd behaviors which I traced to the fact that subclassing NSDictionary actually leads to NSCFDictionary instead, so the NSDictionary methods I was planning to use don't work unless I write them. I found some useful stuff in two other SO questions: here and here. I see that there might be some workarounds but they too have problems.

I was hard-coding some sample clues and answers for testing purposes, with the intent to move to some kind of Core Data approach later. I'm pretty sure that continuing with my present approach will be a lot of work for testing purposes. These are the options I'm considering; any recommendations?

1. Drop the temporary dictionary singleton approach and replace it with a couple of arrays that more or less mimic a dictionary for testing purposes?
2. Switch to NSMutableDictionary even though I don't intend to mutate? The mutable version looks like it might be easier to subclass, but I'm not sure.
3. Go to some kind of global constant arrays and skip the singleton approach for testing purposes (I hope these are the right terms).
4. Write/over ride the needed methods?
5. Bite the bullet and figure out the Core Data part of the app?
6. Something else?

Answer 1

To avoid the headaches of subclassing NSDictionary I would go with a separate singleton object that uses composition to own an NSDictionary. Whether that will work or not depends on what else you hope to do with this singleton, though.

See What should my Objective-C singleton look like? for a discussion on various Objective-C singleton options.

Answer 2

It's unusual to need to subclass any of the collection classes that the Foundation framework provides (NSArray, NSDictionary, NSSet, NSMapTable, etc. and their mutable variants). In fact, it's so unusual that if you think you need to do it, your first move should be to carefully think about why you need to do it, and then sleep on it. (If you want to see someone take a shot at it, check out Mike Ash's recent article on reimplementing NSMutableArray.) The reason that it's so unusual to subclass a collection class is that the collection classes already implement the behaviors required by the standard data structures that they represent: NSArray gives you an indexed list of objects; NSDictionary gives you an associative array; and so on.

From your comments, it sounds like you might be well served by some combination of containers. It's difficult to tell exactly what you want from your description, so I'll have to make some assumptions (which I'll try to state) and hope that even if they're wrong, you may still be pointed in the right direction. So, let's say that you've got a list of questions, and for each question you have an answer and some number of clues. In that case, you might choose to use a dictionary to represent each question. The dictionary could have three keys: 'question', 'answer', and 'clues'. The values associated with the first two keys could just be strings, and the value for 'clues' might be an array or set of strings. And since you've got some number of questions, you'd store each of those dictionaries in a common array. In JSON format, it'd look like this:

[
    {
        "question" : "What's the capitol of New York?",
        "answer" : "Albany",
        "clues" : 
            [
                "It's not New York City.",
                "It's near the Hudson river.",
                "Its name begins with 'A'."
            ]
    },
    {
        "question" : "What's the state sport of Maryland?",
        "answer" : "jousting",
        "clues" : 
            [
                "If you try it, you'll need a horse and some armor.",
                "Kids, don't try this at home."
            ]
    }
]

You could build this up programmatically if you wanted to, but since it's all just static data you'd do better to use the Property List Editor to create the data. Then you can just read it into an array using +arrayWithContentsOfFile:.

Now, about that singleton... It sounds like you really just want an object that'll hold your data and which is easy to access. So, create a class that can contain the array described above:

@interface QAModel : NSObject
@property (strong) NSArray *questions;

+ (QAModel*)sharedModel

@end

@implementation QAModel
@synthesize questions = _questions;

+ (QAModel*)sharedModel
{
    if (self.sharedModel == nil) {
        sharedModel = [[QAModel alloc] init];
    }
    return sharedModel;
}

- (id)init
{
    if ((self = [super init])) {
        _questions = [NSArray arrayWithContentsOfFile:pathToMyDataFile];
    }
    return self;
}
@end

This gives you a shared model object that's easy to access. It's not a true singleton since it doesn't prevent you from instantiating it more than once if you really want to, but that's not usually what people are after when they talk about using a singleton.

Note that the only subclass here is a simple subclass of NSObject -- the arrays and dictionaries are right off the shelf.