Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide better DI support #52

Open
cool-mist opened this issue Aug 4, 2019 · 1 comment
Open

Provide better DI support #52

cool-mist opened this issue Aug 4, 2019 · 1 comment

Comments

@cool-mist
Copy link

cool-mist commented Aug 4, 2019

Problem
HealthManager class creates the injector instance and tries to create the metrics provider class using this. What this means is that the metrics provider constructor must itself depend on a lot of concrete dependencies.

  1. This makes testing difficult.
  2. We cannot use annotation binding in our classes.
    There are probably more such disadvantages.

Example
Consider the following definition.

@Inject
public BasicPolicy(Config sysConfig, Dependency1 dep1){

Here Dependency1 must be a concrete class (with its own inject annotations) for health manager to properly create its instance. There could be a workaround by having it as Dependency1Factory however this is again concrete and defeats the purpose of DI.

Ask
Provide a mechanism to register user defined modules in the HealthManager. For example. an IPolicyBindings with getBindings() getModules() and then that can be applied to the injector by the HealthManager class before attempting to create the metrics provider instance.

@cool-mist
Copy link
Author

The framework initialization

  1. Injects configuration objects into the DI framework.
  2. Expects a metrics provider and a list of policies from the implementations.

Probably providing a abstraction to do might be a good idea. That way the framework does not force the choice of DI for its users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant