Post History

### General information

As indicated in the comments you are looking for something similar to the [Facade pattern](https://en.wikipedia.org/wiki/Facade_pattern). It is still not clear what you are trying to achieve, but the X class seems that it [will tackle way too many things](https://en.wikipedia.org/wiki/God_object). 

In order to avoid adding a lot of logic in one class (even if it only acts as a facade or proxy for other functionality), you should consider splitting the application logic in a way that makes it more maintainable. An example of architecture that does the job very nicely is the clean architecture ([implementation example](https://github.com/jasontaylordev/CleanArchitecture)).

The idea is to split the logic into use cases so that there is a very good match between the business requirement (use case) and how the logic is implemented. The aforementioned example solution relies on a [CQRS implementation](https://en.wikipedia.org/wiki/Command%E2%80%93query_separation) that does this separation.

### Your case (as I can guess from the provided code)

Each use case would be mapped to a class that injects only the dependencies it needs. Examples:

- run automatic tests in a test environment relies on getting server data, getting credentials for that server and a test runner
- running some tests in prod relies on getting production server data, getting credentials and using a smoke tests runner 

Of course, if a scenario applies to all environments, it can receive an environment identifier and act both on test and production.

I know that this is not a direct answer to your question, but I think that such an implementation (or similar) would ensure a good decoupling (e.g. some testing environments functionality should never be run in prod) and increased maintenance (e.g. making changes to test related flows is less likely to mess up with production only flows).