Cool! Can't wait the first DI specific commit and the review :) On 2023. Apr 19., Wed at 14:24, Stamatis Zampetakis <zabe...@gmail.com> wrote:
> 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 >
