Question Mark Hangs Over Dependency Injection
Tonny Madsen, CEO of The RCP Company, has reached a satisfactory conclusion after a long debate about the use of Dependency Injection (DI)in e4.
He has blogged about filing bugs, calling for the use
annotations for invoke in e4 and support for accessing workbench
services without DI. This comes after he dived into the pros and cons of DI in the
forthcoming Eclipse platform, and raised a number of concerns.
To aid his investigation, he examined the e4 contact manager, which displays some of the
features of e4, including DI. Madsen admitted that the DI, as seen
in contact manager, cuts down on the need for listener code,
especially in comparison to the the 3.x version, and features what
he referred to as “understandable code.” After examining the code,
he also decided that the intension becomes clear once you realise
the injection is persistent. This means that changes in the context
are automatically propagated to the view.
However, he wasn’t happy with the other features he found. He
was unsure what type of tooling would be used to access services in
e4, and how developers would be warned about accidental changes in
the e4 string. 3.x uses a Java method chain, meaning that general
Java tooling helps users access the services in 3.x.
But the biggest sticking point for Masden, was the SaveHandler
of the contact manager, which delegates the save functionality to
the doSave method of the view by saving the current contact in the
details view. He was unsure how this would work with the Java
tooling, quick assists and refactoring. Masden also foresaw
problems with maintenance and the testability of this
“Is the new magic DI code worth the lost functionality in the
Java tooling?” he asked. He reached the conclusion that he himself
would use a combination of “traditional” 3.x code and the new-style
DI of e4.
His original blog drew a strong reaction against DI, with Thomas
Hallgreen citing JBoss Seam as a tool that makes heavy use of
DI. He agreed with Masden that, in his experience, DI makes it
harder to debug, and can cause problems with refactoring. He
advised using helper classes, services, and smart use common base
classes instead of DI, to cut down on boilerplate code.
Despite the community’s apparent uncertainty when it comes to DI
in e4, if the e4 team can build the option to use DI, or completely
ignore it, into the new Eclipse platform, then it seems that would
be positively received by the community. Hopefully, the newly-filed
bug reports, are a step towards this.