I think we all agree that DI can be beneficial in general. However, it's hard to say yes or no on something before having a concrete case to discuss; it doesn't have to be a PR but we need to work on a specific Hive use-case and list advantages/disadvantages of the proposal.
Best, Stamatis On Mon, Apr 17, 2023 at 7:33 PM Laszlo Vegh <lv...@cloudera.com.invalid> wrote: > > 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
