Scrap Your Cake Pattern Boilerplate: Dependency Injection Using the Reader Monad (opens in new tab)

Clearest blog post I've read on the Reader monad in Scala. This is something I can see coming to our code base very soon.

The next step for us is monad transformers in Scalaz. We are going to end up with something like Future[Reader[Writer[Problem \/ Result]]] (a few type parameters are missing there; hopefully you get the idea). Monad transformers give a way to flatten this stack of monads into a single monad, which saves a lot of unnecessary wrapping and unwrapping in code. I haven't yet worked out the all the details of using them, though. Should probably do a blog post when I do :-)

Great use of the same example under three different dependency injection mechanisms.

One issue I see with the Reader pattern, however, is that anyone using one of these injected methods has to deal with the monad stuff of using for comprehensions to extract the values, et cetera, whereas with the other two patterns they get to use normal functions.

Put another way: having to distinguish between the "normal" functions in a class versus the injected Reader functions, and not be able to use them in the same way, feels like it would get old fast. I wonder if the author has found this annoying or not.

I do really like how purely functional the Reader approach is though, no state!

I'm not sure I understand the concern regarding the approach using implicits. Sure, you need to add an extra implicit method parameter to each method that requires the dependency, but in the reader approach, every same method needs to be written in the reader monad. In fact, they're really the same concern, since the reader monad instance is just doing the work of threading what would have been implicit in the first place.

It feels like this isn't actually solving the dependency injection problem - we've moved all our dependencies into this global (ish) Config object, but that object is effectively acting as a service registry. Constructing the Config is still going to require a DI strategy (as the end of the post acknowledges), so what do we actually gain from this reader pattern? I don't think it makes testing any easier (if anything it makes it harder, since we have to build up a whole dummy Config, rather than building a small test cake that only includes the dependencies a specific test needs).