Re: [lsug] Dependency Injection

From: Kevin W.
Sent on: Friday, February 15, 2013 3:30 PM

On 15 February[masked]:19, Sandro Mancuso <[address removed]> wrote:
Personal preference. I prefer to have my classes injected instead of creating classes by hand, create constructors and pass the classes around. I'm quick lazy so the less code I write, the better. :)

Doing it by hand is a good thing since every time you want to inject another collaborator into a class you will need to add it to the constructor. This will make you think twice if the class receiving the new collaborator is doing too much. And that's good. Since I already have that in mind, I'm OK with that. 

From the TDD perspective, I can't really see how much it matters. I always test-drive my code in Java and that was never a problem since Mockito works well with the Spring @Autowired annotation, allowing to write my tests already thinking how classes will be collaborating.  

For bonus points, it's possible to make a param both @Autowired and implicit.

Good on legacy codebases with a lot of Spring where you can leave the existing wiring in place even as you start migrating your tests to use implicit wiring.


From: Uberto Barbini <[address removed]>
To: [address removed]
Sent: Friday, 15 February 2013, 14:34

Subject: Re: [lsug] Dependency Injection

Just out of curiosity, which is the advantage that you see in using a framework like Guice (which I like btw) comparing to just inject dependencies on the constructor?

If I can work in pure TDD usually I don't feel the need of a DI framework, but in Java is often necessary for simplifying the integration.

I'm wondering if this is different in Scala enviroment.


On Fri, Feb 15, 2013 at 2:10 PM, Sandro Mancuso <[address removed]> wrote:
Thank you all for the comments. 

Being new to Scala, this discussion was very enlightening. 

After reading all the comments, I believe that Guice is the option that seems more suitable to us and will be the first one we are going to try.

We are also gonna keep an eye on Sindi and will try it when version 1.0 is out with all documentation and examples. 

@Alois: Keep us posted.
Once again, thank you.

From: Pawel Krupinski <[address removed]>
To: [address removed]
Sent: Friday, 15 February 2013, 9:19

Subject: Re: [lsug] Dependency Injection

I've used Guice with Scala and they play well together.
You can use this library to make the binding DSL even nicer in Scala:


On Thu, Feb 14, 2013 at 9:45 PM, Alois Cochard <[address removed]> wrote:

On 14 February[masked]:30, Erich Eichinger <[address removed]> wrote:
Hi Alois,
thanks for elaborating. I'd love to find some spare time and give Sindi a shot on one of the previous projects. Might take some time though... :(
Re reflection & structured types:
is this still the case in Scala 2.10? Didn't dig into compiler details, but I'm wondering why the scala compiler needs to create reflection code to implement structure types? Given the pace of optimizations I wouldn't be surprised if this particular concern is already obsolete.

Very good question, I'm not sure about that, but iirc it really depend of how the structural type is used. Maybe someone else would have the answer, Kevin?
Re compile-time vs runtime-binding:
I agree, a large part of each application I ever dealt with can easily be assembled statically. In fact - leaving an aspect-stuff like transaction management aside - you'd even don't need a DI container for it, a single factorymethod
Well, with a single factory-method you'll end with lot of boilerplate to deal with choosing a specific implementation according to a configuration settings.

With sindi-core + sindi-config, it become quite easy, you just pattern match on your configuration value and choose the implementation (I plan to add some helper to be able to that with even less boilerplate).

But this is suited only when you know in advance all the possible implementations. 
would be sufficient. Regarding my mentioned scenario though, I'd need runtime binding as we bundle different message client implementations depending on the target platforms messaging product - how would Sindi help?

For this kind of scenario (where you don't know in advance the implementation), I think the best approach is to use the "Plugin" feature of Sindi which use behind the scene the Java ServiceLocator:

Obviously you loose the safety for this specific binding, as it become a purely runtime based (classpath), but as sindi return a List in this case you can add a failover strategy or have a default implementation and print a warning.

Cheers :) 
From: [address removed] [mailto:[address removed]] On Behalf Of Alois Cochard
Sent: 14 February[masked]:04

To: [address removed]
Subject: Re: [lsug] Dependency Injection
Hi Erich,
1. About implicits being the biggest evil, I would say that when working with a big team of developers of different skills, it might be better to keep implicits constrained in libraries. Then developer more experienced will create and extend libraries that less skilled developer will then use... but saying there are probably the biggest evil is very extreme, and you might better enjoy language like Kotlin then ;)
2. About performance issue of reflection, I think it's something to not underestimate, without of course going to the premature optimization side of the Force. I think serialization is a great example where avoiding reflection can be really interesting, of course most library that use reflection tend to cache it, but if you can avoid it why not!? You can find some good example of that in recent Miles Sabin work with Blueeyse integration with Shapeless or my experiment here
I think it's pretty obvious for anyone that not only rendering software at Disney have to care about good serialization performance ;)
And finally about DI, cake/implicits, I think you missed my point, why do you think I created Sindi?
If I thought cake/implicits was well suited for large scale project I would never have created such library, but if you look at it in detail you will realize something:
Sindi give you all what you want in term of DI (different configuration per environments, nice way to modularize your application context and split it by domain, ...).
Then you argue about why using it in favor of Spring which is proved to be mature:
Spring doesn't verify binding at compile-time but only at runtime, it's a bit like comparing the usage of null vs Option, and I'm pretty sure that as an exprienced scala coder you realize the gain of safety when using Option over null!
Sindi give you the best of both worlds, because you can use it like Spring to have an easy to read definition of binding (which scale and is composable), but at the same time you have the same safety as if you where using implicits or cake :)
My point was that for small project, implicits/cake can be enough, but I definitely agree that cake might be tricky to scale, specially with the "Bakery of Doom" of path dependent type.
On 14 February[masked]:36, Erich Eichinger <[address removed]> wrote:
> Be careful with structural type, when used for bindings it's probably fine, but one should keep in mind they can generate some slow runtime reflection.
that's something you'd probably deal with once you *really* hit a performance problem - after carefully measuring. And I bet my left arm (I'm left-handed), unless you're writing software rendering the next Disney animation or a high-performance trading agent, you'll find your problem to be elsewhere
> I don't get the idea of using spring scala when starting a project from scratch?
> You can use spring libraries without necessary the spring DI
Why not? Or better: why not any of the DI containers out there? No matter whether you use Spring or anything else, they are mature and provide a lot more than just plain DI like transaction management.
How do you - for instance - achieve different endpoint configurations or -types for different environments? Be it different datastores, messaging technologies, etc. ? Eg I'm working on products that need to plug into different messaging services - how would you solve this with cake or implicits?
From: [address removed] [mailto:[address removed]] On Behalf Of Alois Cochard
Sent: 14 February[masked]:34
To: [address removed]
Subject: RE: [lsug] Dependency Injection
Be careful with structural type, when used for bindings it's probably fine, but one should keep in mind they can generate some slow runtime reflection.
I don't get the idea of using spring scala when starting a project from scratch?
You can use spring libraries without necessary the spring DI
On Feb 14,[masked]:18 PM, "Erich Eichinger" <[address removed]> wrote:
first of all, ideally the DI container you are using shouldn't affect your class design at all. Its only job is to assemble your components.
I have used the cake pattern in a medium-sized application and have to admit I still got mixed feelings about it.
Alternative thought: To reduce the number of types in Scala you can also make use of functions and/or structured types for your injection needs. This is what I ended up making lots of use of, it makes unit testing very easy - no mocking needed, since all you pass in as dependencies are callback functions.
I know (but never used it myself) that Jan Machacek has done quite some work on using Spring to assemble your Scala components, see e.g.
From: [address removed] [mailto:[address removed]] On Behalf Of Noel Kennedy

Sent: 14 February[masked]:21
To: [address removed]
Subject: Re: [lsug] Dependency Injection
We use the cake pattern after a brief fling with just using abstract fields.  
I have run into the path dependent type problem a few times since we refactored to using cake.  Briefly our problem was caused by trying to share an instance implementing a contract, from one cake inside another cake.  Every time this happened it made me realise I was actually trying to share state and I refactored out an actor or a singleton or whatever and the problem goes away.
Pick a good naming convention for your traits if you go with cake as you will need it!
You can use ours if you like
trait xxxDependency {
trait xxx {} // The unimplemented service contract.
def xxxService : xxx
trait xxx{implementation name}  extends xxxDependency {
//self type to all other dependencies
trait {implementation name} extends xxx {} //actual implementation of service
cake cons
Head scratching to work out how it works
Boiler plate traits
Path dependency type problem discussed above 
cake pros
Compile time checking of dependencies.  
Everything is wired up in code 
(with an IDE) you can easily follow dependency graphs
One less framework that you need to learn and and fuss over.  
And no xml
On 14 Feb 2013, at 15:51, Sandro Mancuso <[address removed]>
Hi all

We are starting a project with Scala but none of us are very experienced with it. 

We were looking for ways to do dependency injection and we found the following:

Cake pattern:


We also find a few dead repositories on github but nothing very relevant. 

I was wondering what you guys are using of DI in Scala. Pros and Cons?

Maybe because of my lack of experience in Scala, I found the Cake Pattern a bit verbose and SubCut a bit intrusive since I need to add SubCut stuff to all my classes. At least, that was my impression when reading the tutorial. 

Any views?


Our Sponsors

  • Scala Dojo

    Web site for monthly Scala Dojo

  • Scala Jobs

    Google Group of Scala Jobs in the London Area

  • ScalaDays-AMS

    Price is 650 Euro with code “scalaug” for ScalaDays Amsterdam

  • _.underscore

    Scala consultants, trainers, and developers, based in London, UK

  • Springer

    Help and supporters of the monthly dojo

  • Mind Candy

    Help with the Adv Scala Meet-up

  • Skills Matter

    Provide the venue for many of our meetings.

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy