Appropriate way to organize dependency with external class avoiding high coupling

Question

I was design a server communication module of native application.

As starting point for now I have 3 classes:

1. HttpSession — class which contain all necessary data for sending requests.
2. ResourceManager — class for handling loading, parsing and storage server data. It's not thread safe and needs to be used within a single thread, since there several child classes of different type dependent on content type. Each of them creates per user interaction.
3. FileLoader — special class for queuing files for load/upload also it restores all unfinished downloads. It's thread safe since there separate threads for loading and queuing.

So ResourceManager and FileLoader both using HttpSession, I decided to use composition there, so both of them contains HttpSession passed by ref via c-tor. Here we go to actual issue, I need to use FileLoader inside ResourceManager, since some of the resources requires files to be loaded. Currently I have a few thoughts in mind:

1. Use composition for FileLoader and pass it inside ResourceManager, well that's will cause high module cohesion, but was about to keep them separated
2. Use new instance of FileLoader inside ResourceManager, will break the rule that ResourceManager is single threaded class, also spawning new threadpool for each class instance such a bad idea. I think it would be better to stay with 1st way
3. Keep file URLs with required action then somehow return them from ResourceManager and finally pass to FileLoader, but I don't know an elegant way to do this

My question if there better way to coordinate my classes in such a case, maybe some well-known design patterns?

UPDATE 1:

Okay, I thought about 3rd variant... so here some ways to implement that I have in mind:

1. Pass function to c-tor of class that would allow me to load files, concrete implementation may be different. Disadvantage that it might be few methods ResourseManager require, so c-tor might have a lot of parameters.
2. Add methods to setup callbacks for loading. I like that you may specify callbacks only when you need it... but it would be difficult for other developers to know when you need it exactly huh. It's not appropriate and such a bad design.
3. Define something like FileUploadProtocol interface class with all necessary methods ResourceManager might need. I find it a cool approach, but the disadvantage is that you need to implement your own class or wrapper under your class.

• Rik D: It's not really clear what your actual problem is. You mention avoiding high cohesion, but high cohesion is actually something to strive for. Furthermore you say you have three classes, but you also mention ResourceLoader which isn't one of the three mentioned. Could you try to clarify your question a bit?
• Liastre: @RikD thanks for such a useful reply. I meant coupling, not cohesion for sure, seems I used wrong term. ResourceLoader was just a typo, there only 3 classes. Question edited :)