Just for information: The "generally recommended" implementation of resource management, as crystallized from the many discussions here on GDnet, coarsely looks as follows. (We speak of assets here, not of operational resources, don't we?)
a) There is an own manager for each kind of resource.
b) Management is not done monolithic in a single object. Instead, the ResourceManager is a front-end that co-ordinates a couple of collaborators. Have a look at the facade software pattern for an introduction of this scheme.
c) One collaborator behind the facade is responsible for caching. It is e.g. derived from a HashMap, using the resource identifier as key and the resource as value. Because it is an own object, storing the resources can be done in a resource type specific way, giving the ability for optimizations.
d) Another collaborator is the resource loader. Its job is to read resources from mass storage when being instructed to do so.
e) The manager is *ever* the owner of a loaded resource. A client that wants to use a resource *ever* requests the belonging manager for the resource, and *never* frees it after getting access.
f) If the manager is requested for a resource, it looks up the resource in the cache and returns it if found; otherwise it calls the loader to load the resource from mass storage, puts the result into the cache and returns it.
g) It may also be favorable to have a resource factory per resource type as a collaborator. If needed by the game, the manager can provide public access to a factory so that clients can generate resources on the fly, e.g. for dynamic content creation. In this case I'd suggest factory functions within the manager's interface.
h) Do *not* use static objects as resource manager. The managers should be accessible from what Sean Middleditch calls "spaces", referred to from game levels. This allows resource groups to be separated and freed in blocks / at once.
i) Resources need not necessarily be derived from a common base class, but I also don't see it as to be avoided obsessively.