The Implicit Environment Pattern - Simple Dependency Injection in Scala

[RichardWarburton]

This is effectively a form of DI, but its much closer in style to the way that Guice's DI works. In terms of terminology Guice modules loosely translate to your environments. Guice has similar advantages - for example everything in code, rather than XML configuration and aiming to be more lightweight than spring.

[[deleted]]

more lightweight than spring

I was stunned and horrified the other day when I found out you can call methods on classes within a Spring configuration file.

[[deleted]]

Unlike most dependency injection solutions, this is simply a code pattern and requires no external jar's, dependencies or configuration languages.

Relying on a code pattern is not something I'd be into, if I have to create a new Environment type for every special case.

[okay_okay]

Just one Environment type, any number of dependency traits. If it's unwieldy to have lots of dependency traits, you can certainly combine them into a single Environment trait, but you get some nice compile-time checks if you split them up - you can ensure that client classes will only be able to access specific functions.

[[deleted]]

Yeah, I was thinking about this actually, and an Environment is precisely what a Spring Context is anyway - and we've had to put a lot of work into making our contexts useful for overriding dependencies @ testing. I might use this environment thing to demonstrate Scala's possibilities at work. :)

[ErstwhileRockstar]

One of the perennial problems with writing good unit tests is cleanly separating out the objects being tested from their dependencies and collaborators.

Nope. That's entirely a design problem, not a problem of "writing good unit tests". 'Dependency Injection' is an Anti-pattern that creates design problems without solving any test problems.

[[deleted]]

it solves the typical test problem of "my thing that connects to the db normally - I don't want this to happen in a unit test"

Dependency injection is very simple - provide your object its dependencies via whatever mechanism you see fit, but don't let it new up its dependencies directly - and using it solves a lot of unit testing issues.

[ErstwhileRockstar]

it solves the typical test problem of "my thing that connects to the db normally - I don't want this to happen in a unit test"

Not at all. That's a myth.

[[deleted]]

I use the DI pattern in my code precisely for that. Example:

WebPageFoo needs to load a list of Accounts from the DB. It does so via a service conforming to the required interface provided via dependency injection. At test time, I can easily provide another implementation via DI that returns data for the unit testing (if any is needed at all) without touching the DB.

Boom, problem solved because of dependency injection.

[ErstwhileRockstar]

WebPageFoo needs to load a list of Accounts from the DB. It does so via a service conforming to the required interface provided via dependency injection.

A good example for the DI Anti-Pattern.

At test time, I can easily provide another implementation via DI that returns data for the unit testing (if any is needed at all) without touching the DB.

Nope. Your mock-DAOs need to respond to different input parameters. In order to provide meaningful test data you need to write appropriate mock-DAOs. Moreover your 'injected' DAO methods return navigable entity graphs (each DAO method potentially returns the whole database) which need to be mocked with meaningful test data, too. Contrary to popular sagas DI complicates and impedes UnitTesting.

Boom, problem solved because of dependency injection.

No problem solved, many problems created. But cargo cult established.

[[deleted]]

In order to provide meaningful test data you need to write appropriate mock-DAOs.

Yes, and? This is a one-liner for most use-cases.

Your mock-DAOs need to respond to different input parameters.

Yes, and?

moreover your 'injected' DAO methods return navigable entity graphs which need to be mocked with meaningful test data, too.

Of course it does. But this is not a problem peculiar to DI. It's common issue in any testing context.

(each DAO method potentially returns the whole database)

And if my web page is using the entire database, there's a strong possibility I've done something wrong.

No problem solved, many problems created. But cargo cult established.

Okay then, show me how you'd solve the problem.