Chicago.PM - Dependency Injection (also: Beam::Wire)
At this month's Chicago.PM meeting, I gave a presentation on Dependency Injection and my new module, Beam::Wire.
[EDIT: The presentation doesn't appear to work on mobile devices. I'm trying deck.js, and I'm not sure I like it.]
When I started my current job, I was introduced to the custom Dependency Injection framework they built. At the time, I was dismissive: "It's programming via config file, which is always limiting (and so, a Bad Idea)." "It's something that Java needs, but not Perl."
Slowly, and with great reluctance, I learned where dependency injection fits into a large framework: It removes the work of creating objects. Any object. Anywhere.
For an idea of how powerful this is, do a quick search through your libraries and scripts (except for tests) for /->new/. Hopefully, the results will only be defaults (otherwise you've got tight coupling, another problem DI can fix). But every time you call an object constructor is another place where dependency injection can reduce the amount of code you write and maintain.
So, since the bureaucracy means I can't simply open-source the DI framework we have at $dayjob, I decided to make my own.
Beam::Wire is available on CPAN. There are a lot of features planned for it, so stay tuned! If you're interested, up-vote Beam::Wire on play-perl.
In general, if you want to maximize the number of people who can view your slides, you should use PS, PDF, HTML, text, or some other offline format which you probably already used to prepare them.
I am very interested in the combination of DI with Moose Roles. The presentation is very interesting - are you able to show any more detail on where you were going with the DAO type role as on slide 31?
Your Beam::Wire looks very promising - I am looking forward to reading more as it develops.
The DAOInterface role is just an interface. By implementing the required methods, you can create an implementation that you can then give to another object. So I could have a DBIx::Class implementation of the DAOInterface, or a MongoDB implementation of the DAOInterface, or a custom version that interfaced with a custom database via DBI.
It's not a very robust way of defining an interface (the arguments are not being checked), but it at least makes the author do a bit of reading/thinking. I'm having a bit of fun working with this idea of Perl Interfaces that I'm sure will at least inspire a blog post or two.