Hi all, Sorry for not answering for so far, for some reason I did not receive your answers in my gmail account. I’m happy to see that there’s a conversation around the topic, so let me add my opinion on your points.
First of all, introducing a DI framework does not mean a large scale refactoring. A suitable module, or a well-bounded set of components can be chosen as the first candidate. It’s also important that nobody will be forced to utilise the DI container when writing features, or to redesign existing code when it is being touched. As for the aim: I’ve worked quite a lot with Java and .Net DI frameworks, and my experience was that having a DI framework greatly reduces the effort to write well organised and maintainable code. While well organised code can be written without DI frameworks too, the lack of such framework makes it much more easier to write poorly designed code (bad scoping, lifecycle issues, visibility issues, etc). On well-organised I mean: Design patterns: DI containers make it easier to write code using the well known design patterns. For example you can implement factory, wrapper, adapter, etc patterns by simply using the offered features as it is supposed to do. Streamlined component initialisation: No more spaghetti/boilerplate component init methods Well defined component scopes (lifecycle): DI frameworks support various component scopes, which offers a fine grained control over component lifecylce -> Singleton, one component per thread, one component per request from DI container, etc. Organised and visible component/class dependencies: Through constructor injection all the dependencies of a class are visible (unlike static method calls). Using this approach it is impossible to create circular dependencies which lead to object initialisation issues and hacks. By requiring all deps during object creation it’s way easier to detect or avoid unwanted dependencies. It also makes easier to better organise the code into packages and modules Enhanced testability: I have explained this earlier. Well defined component visibility: No need for “union-all” context objects. Instead of having context objects with references for all of the components which may required during the execution, each execution step can obtain the necessary dependencies from the DI container. Also, no more public static methods, or class instances. In order to let some component accessible from everywhere, there’s no need to make it public and static. DI frameworks also offer nested/sub contexts to limit/control visibility. My original mail was supposed to be a kickoff, to start talking about DI. Before creating a PR with an example in Hive, I would like to have a common agreement that we want to do this, and there is no blocker which prevents us from doing it. Once we have this agreement I can create a working example and demonstrate how it will help us in the future. Regarding the stability and performance issues: Of course those must be addressed as well, but as Stamatis pointed out, Hive is an open source project and everybody can have its own initiative in parallel to the others’. In Java I have the most experience with Spring, so I would prefer choosing it. It became huge by now, but it’s modular. We are not forced to use all of the offered features, if we want a pure DI container with some basic extensions, we would only need spring-core, spring-beans, and spring-context. It has several extensions and supports tons of other well known frameworks and/or technologies. Best regards, Laszlo Vegh
