My thoughts about DI, dry-container, dry-auto_inject, dry-system


#1

I don’t have any commercial experience and I have made only simple apps as my hobby and education, and I have just write one very simple application using dry gems, so I am not sure my thoughts make any sense, but I want to share them.

I like the idea of small function-like objects because I don’t know how to create and organize bigger objects. With small objects I don’t have to think how to design them, because if they do just one thing, then it is just a one way to design them. I have noticed that with this approach I have to use many objects (like 40 for a simple console calculator), but most of them are reusable control flow objects and only about 20% of them are objects that I must create from scratch (and they are very simple).

This small objects are connected in a dependency tree graph and it is not possible to track this tree (it is growing and changing) without having a graphical image of it. I use a mind map tool for this.

dry-container is very helpful especially because it can stub objects during integration tests.

dry-system is good because it automatically registers objects. But this alone is not very helpful. The best thing is auto-registering plus auto-injecting. Because those things together allow to create objects that are close to root of the dependency tree automatically.
And I don’t know yet if it can automatically register for example a Hash or Array or it must be always a custom class defined in a file with a proper name.

dry-auto_inject is IMO the less helpful. I think I can do the same thing with just writing regular initialize methods with default arguments (taken from a container). dry-auto_inject has only two strategies of passing arguments and it forced me to rewrite a class because my class was expected arrays of objects (they were registered by the container) or regular args mixed with keyword args and I think dry-auto_inject could not handle those things.