Past Meetup

February's Code Share: Dependency Injection - DI Another Day?


Since the Spring framework first challenged EJB2 with a simpler way of producing java web applications, dependency injection (DI) (sometimes [incorrectly?] referred to as Inversion of Control) has become a mainstream technology in the Java world. However, when talking about other languages there seems to be far less talk about dependency injection. Is this because other languages have features that java lacks, because of the types of application that Java is typically employed to develop or some other difference in the java ecosystem?

Is dependency injection good or bad? Is is accurate to say that dependency injection is less prevalent in other languages? Is it that the frameworks themselves are somehow bad for us rather than the technique itself? Nay Pryce has this to say:

“We don't use a DI framework. Personally, I find them more of a hindrance than a help in most situations because they don't distinguish between "internals" & "peers" (p 50) and so often guide design to a violation of the "composite simpler than the sum of its parts" principle (p 53). I find that I need to clearly understand, and therefore express in code, the dependencies between the objects in the system. Hiding that information away in auto-wiring frameworks or obfuscating it in XML files that, furthermore, cannot be easily refactored just gets in my way when I later need to understand the code and modify it.”

In this code share we’ll examine examples of using dependency injection in different languages, different frameworks and without frameworks and discuss whether DI is harmful.

Are all frameworks created equal? What makes a good or bad DI framework?

Here are some DI frameworks for your consideration - feel free to use the comments to link to others

Spring (Java) Guice (Java) Seam (Java) Boing (clojure) Pico (Java) Parsley (Actionscript)

February’s Challenge

Use dependency injection (with or without a DI framework) in the language of your choice to build an application that determines whether an input string is a palindrome. In order to motivate the use of DI your application must be separated into (at least) the following parts:

palindrome service - determines whether the string is a palindrome persistence service - used to lookup a string to see if it’s a known palindrome (fake this - no need for access to a real persistent store) presentation controller view Aim for conciseness but not obscurity - we want to focus on the use of DI and so we want to minimize the amount of non-DI code, but on the other hand we still need something that is readable.

Please email Dave & Ged your solutions by 3rd February.

ThoughtWorks are delighted to be sponsors of the December Code Share!

Please Note -

At previous events LJC members have found this venue/particular room hard to find.

This event is being held in the Francis Bancroft Building - Room Number - FB 2.40.

Please see this map for further information (the building is numbered 26 on this map)

The actual signs at the building will say 'Bancroft' building only rather than Francis Bancroft.

Directions -

From Mile End Station you will need to turn left out of the station and then continue for 5 mins approx. up the Mile End Road and then cross over the road to the QM campus and go into the East Gate. This is the first entrance to QM you come to when coming from the direction of Mile End Tube. Continue straight on up Westfield Way for a couple of minutes and then bear left at the Curve cafe. The Bancroft Building is on your right (number 26 on the map).

This event is being hosted in conjunction with the GDC