feature request: context parameter
peerhenry opened this issue · comments
Feature request
As a developer I want to have the option of specifying a context as a string when registering dependencies so that I can register multiple interface implementations or subclasses without having to autowire any classes.
Motivation
Using a context, all classes can be kept loosely coupled from Poodinis at all times. Also, the developer can structure the dependency tree in one place rather than having to modify classes to specify autowire attributes.
Technical requirement (suggestion)
Associate the field
Registration[][TypeInfo] registrations
inside the class DependencyContainer
with a context string, ie:
Registration[][TypeInfo][string] registrations
and overload the register method with a string parameter that allows the client to specify a context string parameter. Not specifying a string will result in registering in the "default"
array. Resolving dependencies will first try to resolve within their registered context before reverting to the default context.
Could you give me a usage example? This request confuses me because there's already context registration in Poodinis, see https://github.com/mbierlee/poodinis/blob/master/TUTORIAL.md "Application Contexts"
This in combination with constructor injection helps you set-up dependencies without having to modify the classes themselves.
The goal would be to be able to register multiple implementations without using autowire. The word "context" may be a poor choice here because it's already used.
Example:
Suppose a class PetStore
has a dependency on an interface Animal
.
auto container = new shared DependencyContainer();
container.register!(Animal, Dog);
container.register!(Animal, Cat)("cats");
container.register!(IPetStore, PetStore).dependencies("cats");
auto store = container.resolve!IPetStore;
This setup will mean three things:
- The resolved store now has the
Cat
class injected. - Any clients of
Animal
registered without.dependencies("cats")
will getDog
injected. - If PetStore has any other dependencies that were not associated with the string "cats", they will be resolved as usual.
Interesting idea. I would call them qualifier groups. Named qualifiers were on already my list, this would make the concept even more useful.
Even though implementation would be fairly straightforward, for the sake of not over-complicating the design I am inclined to close this request as a "won't do". The same can be achieved by setting up multiple dependency containers.