KSP and little configuration,
Tracer generates extensional properties oriented to interior traceable elements, which realizes dependency injection in a novel way.
- Powerful: generic types and variances are supported
- Fast: no cache or rum-time reflection
Transit from general code
to this tracer sample below.
See many more features on tracer.
What is a typical use case for this framework? I see it as a tool that helps creating graphs of interconnected objects. I’m just trying to figure out some real world examples for it.
I find the phrase “dependency injection” very confusing here, because it doesn’t solve the same kind of problems as typical dependency injection frameworks. As a matter of fact, I think it is somehow the opposite of the dependency injection. The whole point of dependency injection is to make connections between objects loosely-coupled. Your framework does the opposite. Objects are very tightly-coupled, they reference other objects directly.
If we have a graph of 20 objects, then each of them have to “know” the whole object graph to be able to reference its dependencies. If we change anything in the graph, we move the router to another room, we have to adapt the code everywhere. Your original implementation of
House was more loosely-coupled and easier to adapt to changes than when using your framework.
LivingRoom didn’t know how to acquire its dependencies and this is good. After the change, it has to know how to find them.
It reminds me the service locator pattern, but with auto-generated object ids.