I have a bunch of resources (images, scripts, audio etc) that is to be used by many different object across a program. Obviously i don't want each object to load an image, use it and then delete it, i need some resource management.
Now a resource manager needs to be globally accesible and it needs to have a single mutable state, which immediately has me reaching for the singleton pattern.
Would you say this is one of those places where a singleton is in order?
It's generally frowned upon to use singletons and i'm not sure whether my initial assumptions about the scope and state of a resource manager are necessarly correct, i'd just hate to have to pass a resource manager around from object to object throughout the program.
I've thought about some alternatives. I could make the resource manager a monostate object (making the list of currently loaded resources shared between instances of the manager), but in this case that would be functionally equivalent to a singleton, only instead of calling GetInstance() on some globally accessible object i'd have to instantiate the resource manager wherever i wanted to use a resource.
Another possibility is to split up the resource management across the different types of resources, and then have each of those objects report back to some central list of resources that have already been loaded. I imagine it looking something like this:
...ImageResource::LoadResource() then checks with some static class whether this resource has been used before and is already loaded, and if not, it loads it and adds it to the list. This means that i wont actually have to deal with any globally accessible class in the different objects of my program, the Resource classes will do that for me.Code:ImageResource img_res("./resources/images/img.png"); img_res.LoadResource(); RenderImage(img_res.GetImage());