Home » Software Development » In today’s post-OO world, is dependency injection still relevant?

About Adam Warski

Adam Warski
Adam is one of the co-founders of SoftwareMill, a company specialising in delivering customised software solutions. He is also involved in open-source projects, as a founder, lead developer or contributor to: Hibernate Envers, a Hibernate core module, which provides entity versioning/auditing capabilities; ElasticMQ, an SQS-compatible messaging server written in Scala; Veripacks, a tool to specify and verify inter-package dependencies, and others.

In today’s post-OO world, is dependency injection still relevant?

It’s 2015. Most of the new popular languages are more or less functional. The old ones, like Java, gain functional programming elements. In Scala, people are increasingly leaning towards the pure side, using more FP and less OO. So – Dependency Injection? Really?

You could say that DI is just using (constructor) parameters. I’m saying that as well in my talks on no-framework DI in Scala using MacWire. Passing parameters is the basic building block of FP. So why give it another name? Is DI a separate concept?

Different kinds of parameters

Recently I had a short discussion with Alois Cochard on his blog, where he describes an approach to DI similar to mine. He also once wrote a DI library (Sindi), so it’s good to know we came to similar conclusions. But that got me thinking – maybe there are two kinds of parameters?

One kind of parameters would be ordinary “data” parameters. That’s what we pass around functions, manipulate, modify, persist, etc. These are entities, aggregates, collections, case classes. The other kind would be “service” parameters. These are classes which encapsulate business logic, allow communicating with external systems, provide data access.

While you could of course use only FP to create an entire system end-to-end, I think a number of people (me included) find it convenient and readable to use FP “in the small” and objects “in the large”, as described e.g. in the Programming Scala book, or in this Quora question. So you have some possibly pure FP code manipulating your data, implementing the core business logic fragments, and that is encapsulated (organized into?) by objects (you could call them “services”, “modules”, or some name better reflecting the overall responsibility).

That’s where DI comes into the picture. It can be very useful when wiring the “service”/”module” object graph. The means to create the object graph may be the same as when dealing with any other kinds of objects – either by doing DI manually, or with the help of MacWire, or with a container – but the way we are using parameters feels different.

Environments

Another way to think about the “data” and “service” parameter split is that the services form an execution environment for our (pure-FP or not) code. Such an environment may contain services for accessing the database, communicating with the user, etc. Currently we use the same mechanism – parameters – to define the environment (e.g. via constructor parameters), as we use to pass data around functions. But maybe in some future programming language, these concepts will be separate?

Or instead of creating a separate mechanism, which could end up as poorer, “shadow” functions, we could have some more convenient syntax for creating and using environments?

A good example of such an “environmental” parameter is the quite commonly used ExecutionContext in Scala. Currently it is very often passed as an implicit parameter (and it’s contagious, the implicit is needed in every place we want to manipulate futures, from method to method …). At least for me it is a different “kind” of parameter then, let’s say, a Set[Person]. Wouldn’t it be great if we could just assume that our code is executed in an environment, where “some” execution context is provided? Other examples might include “some” way to access a database; or “some” way to talk to a webservice.

Such “environmental” parameters are often what we want to swap out for testing, or change depending on deployment configuration – “canonical” use cases for dependency injection.

Finally, Alois Cochard also pointed me to a talk by Tomas Petricek on a calculus for environmental parameters (it’s just 20 minutes!). Time to study coeffects? :)

(0 rating, 0 votes)
You need to be a registered member to rate this.
Start the discussion Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy

Leave a Reply

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
Notify of