Question

I commonly create apps that require storage of data, and this data is used across the entire program. It’s not much, though, so I usually use NSUserDefaults to load/save this data. However, the saving/loading code, along with packing/unpacking the data, takes up space, and I thought moving this code to reusable methods inside a global singleton would be a good idea. It seems to have worked well.

Even so, I’ve read a lot lately on the evils of singletons and global objects, and I’ve started to have second thoughts. People often say that the use of singletons is almost always an indications of poor design. For the most part, I’d disagree (I think simple uses like this are a good design pattern), but I’m certainly no expert on the matter.

So, is using singletons even in a simple way like this bad? If so, what’s the better alternative?

Answer 1

I definitely don’t agree that singletons are evil. They are sometimes overused perhaps but on some occasions are just perfect for the job. In some applications it makes sense to have some kind of general data manager. The singleton pattern is used extensively in the SDK itself (app delegates, shared managers, default centers and so on). Most often these are not “pure” singletons, as in you can access a shared instance but can also create new instances if necessary.

The question you need to ask yourself is whether it would be useful to have access to a single instance of a data manager from anywhere at anytime, if it isn’t then a singleton is probably not needed. If you are going to be using singletons in multi-threaded environments however, you do need to worry about race conditions (can one thread modify a resource while another is accessing it), the documentation has good explanations on how best to achieve this in Cocoa.

Let me try to explain with an example – Am using some code from a game I wrote. Let’s say you have a GameMap class and a Tile class. The GameMap represents a 2 dimension grid of Tile objects.

GameMap *gameMap = [[GameMap alloc] init];
NSArray *theTiles = gameMap.tiles;

The instance of the GameMap owns the grid of tiles, and creates the tiles when the game map is created. No singleton needed.

You may say “but I only have one GameMap at a time, what’s the big deal?”. What about loading saved games, or loading new levels? Well that becomes as easy as:

// In whatever class object owns the game map
self.gameMap = [[GameMap alloc] initWithSaveData:saveData];

In conclusion, create an instance of a class that has code to manage other instances of things. Keep as little global as possible and your code will be more scalable and maintainable.