Hmmm, I'm pretty sure I'm destroying all encapsulation and modularity by closely tieing together the renderlist and the resource manager this way..

Right now I'm creating a renderlist directly through the resource manager.. To keep in the spirit of a generic resource manager, this simply won't do. But my question is, what system would create a resource list, if not the resource manager?

Right now, on other forums, this system is being challenged as unmodular and not encapsulated enough for its own good. Maybe I need to re-evaluate what exactly a resource manager should do...

A. Look up resources by string-based key and protect against multiple copies of resources with the same key.

B. Manage and protect the lifetime of those resources (creation and destruction; prevent users deleting a resource via a raw pointer)

A suggests that I should add the functionality to keep a list of loaded resources, as well as a reference to the resource accompanying the string. I should be able to search for a string, check its existance, and not load the resource again.

B suggests that the resource manager itself should handle the loading of a resource, the destruction of a resource, and prevent clients from deleting the resource. I.E the Rendering engine should not be able to remove a resource from the system.


1. The worst thing you could do it provide your client raw pointers. But the client needs to have some form of the actual resource or it won't be able to call methods on that resource.

This means, when a client, such as a rendering engine, requests a resource, we shouldn't give it a raw pointer. That could lead easily to dangling pointers and memory leaks. But the engine needs something, so we can give it an object that holds the pointer.. a proxy object, or, I.E -> a handle.

2. The resource manager itself simply keeps a list of resources and their names. It is responsible for allocating these resources (it does so in LoadResource(), which I haven't written here) and freeing them as needed (either when the manger itself is destroyed, or when the manager decides the resource hasn't been accessed recently enough, or the client calls a method on the manager to forcibly release a resource).