You have that a little backwards, methinks. Part of the argument is, as you say, that the manager class is too monolithic and should be refactored into several, more tightly focused classes. But a manager means different things to different people and in different contexts. Like Hodgman said, it could be a cache, a factory, or a pool,
Which to me is why resource cache is just a pointlessly specific name as manager, it's supposed to be an abstraction. You know, you ask for a resource, you get it back, that behavior is the same in all three things you listed. Why does the name have to reflect the behavior of how it works under the hood? Sure if you want to go in detail I guess in your file list having cache is more specific, but to the rest of the program looking in it is just specifics that don't imply anything about design. I could just as easily call it a resource pool and put -all- the loading code into that one class.
Which is why it sort of boggles my mind how many replies in this thread are like, "If I see the word manager, oh man, red flag!" You don't even know what manager means yet and you're already assuming it doesn't follow some mythical golden rule of design, silly stuff.
or maybe even something else, or some combination of them, depending on what it's managing. Those are all well-defined computer science terms. Cache is the typically used suggested alternative because texture manager tends to be such a popular how-do-I- topic.
I'm a firm believer in something most books, tutorials and teachers try to push about programming, and that is the idea of abstracting away how something works internally from how other parts of a program use it. That happens no matter the language, you can do the same thing with subroutines in assembly. What it comes down to is that if you need to ask a major system for something it should for all intents and purposes, work automagically for you. Compartmentalizing code like that makes it much easier to manage, if anything the topic we are specifically covering is when you should decompose the internals of a manager into smaller classes and benefits of doing so.
I agree that once it's broken down into a system of classes, there is typically one class, or sometimes a small subset of the classes, that act as the interface to the rest of the program. But that interface is more tightly focused, and if designed well, rarely needs to be global. Often the class acting as the public interface may not even be the cache or factory or pool that served as the core of the old manager class.
I use the word "manager" in my code for such systems all the time and I don't make it global, I don't make it a singleton and if it is in my BENEFIT I decompose it into more classes internally, that doesn't have anything to do with the fact it is named "manager." I name it manager because to the rest of the program it is just that, a manager, it is presented as a monolithic class to the rest of the game because that is its job, it is to appear to be the interface to get ahold of resources and the rest of the game could care less how it works under the hood.
I'm sorry if I'm repeating myself ad nauseum but as I go through your reply it just strikes me that you seem to associate the word manager with "bad design" and although that may be true sometimes, especially in the case of novice developers, it really doesn't say anything about the architecture. Personally I've seen "manager" done a hundred different ways and a lot of them are very awful so it's not like we're talking about one medicine prescription here.
Ultimately, the manager phenomenon is a manifestation of inexperience and ignorance. It's relatively easy to learn to code self-guided from books and we sites. It's more difficult to learn good design and to think like a programmer without guidance. And so newbies create managers because they haven't gained enough theory to better define what they intend the class to do, and they make them singletons because it looks like an answer to their design problems. And they get away with it for a time, because the new problems are much more subtle. And then they start looking for better ways to do things when they finally stumble. And they get told that managers are bad and global are bad and singletons are bad. And if they're fortunate they're given advice on better design. And if they're really fortunate it's comprehensive and easily followable. That's just how it is in the Internet we live in.
Yet more talk about managers being globals or singletons or bad design or what have you, a massive generalization. I would also like to point out that even though you have such a mystical view of perfect code(as do a lot of other people here) in reality a lot of AAA engines and games out there massively abuse things like globals, singletons, static objects all over and messy cross includes and bad design, these things are bad design because we come up with negatives associated with them. But the thing is, people still use them and probably always will, and honestly I'm one of those people that has learned very heavily that not everyone's advice is to be taken blindly and that you have to look at things with perspective.
The biggest fact with programming is that it is situational. I often see people pushing this massively overcomplicated component based design that they tote around like religious talk for many different subsystems of a game and the fact is: it is often overcomplicated, massively personalized, doesn't necessarily do something -better- and finally, it takes a hundred times longer to implement, and is ONLY good in a situation where how generic it is can be utilized. There's no silver bullets here, saying the word "manager" means bad is like saying "all bit shifting is bad" well of course thats silly, you can do a billion terrible things with bit shifting and also a billion good things depending on the situation.
So, some caches may be part of some managers or management systems (or modules or whatever), but I disagree that it's all semantics.
Well of course, how could it be semantics if all your assumptions so far are that any "manager" must be one big brand of bad design, I never once suggested that a manager had to be a singleton or global or all the code shoved together or anything like that. The OP asked for how these systems tend to work not why his name "manager" implies he is a terrible coder.