[LRUG] Dependency Injection and DHH

[John Cinnamond]

> I'm wondering what those who were at RailsConf and listened to DHH's
> keynote - or have watched the video:
> http://www.justin.tv/confreaks/b/522089408 - thought about his description
> of dependency injection making code worse?
>

tldr; somebody on the internet was wrong and I am outraged about it.

It took me a while to get through the video, I think mostly because it was
a crock of shit.

There are many things discussed in the video. Sleepyfox's question was
specifically about dependency injection making code worse so I'll try to
only talk about that aspect of it, although it can be hard to disentangle
it from other aspects of the talk.

I am coming to the end of reasonably large project where we tried to follow
the SOLID principles fairly religiously, and of course this includes a lot
of dependency injection. This is a ruby project but not a rails project.
It's worth saying upfront that I do not think that this is directly
applicable to rails projects - you spend too much time fighting the
framework. We do have an admin app written in rails and I used some service
patterns but that has nothing to do with dependency injection.

I have mixed feelings about the 'success' of following SOLID principles. It
makes code harder to write and you will spend a lot of time writing
boilerplate code or following repetitive processes. I think that in general
it makes trivial code harder to write and difficult code easier to write.
That seems like a pretty good tradeoff to me.

The principle reason I use it is nothing to do with code quality, or ease
of writing software, or - god forbid - writing tests. It is to increase the
level of confidence that I understand the impact of changes I make to the
code as it evolves. I.e., in general I am more confident that changes I
make to the code will not have unintended consequences when I follow SOLID
principles than I would be if I didn't.

The reason I have that extra confidence is because I am extremely
prescriptive about making the communication between different parts of the
system (units, if you will) explicit and testable. In retrospect, I think
that ruby and all dynamically typed languages might be fundamentally
unsuitable to this kind of prescriptive thinking. To try to compensate for
this I wrote a gem to try to enforce duck typing (
https://github.com/jcinnamond/lawyer) but this is ultimately both
inadequate and somewhat perverse.

In making the communication between parts of the system explicit and
testable I end up bringing in some other desirable qualities such as
loosely coupled classes and easily substitutable behaviour (the L in
solid). It feels like I'm moving closer to Alan Kay's idea of OO
programming being about the messages between objects.

Inversion of Control and Dependency Injection sometimes fuck with me.
Occasionally I am looking at a class and I can tell what one of it's
dependencies does (from it's name) but I don't know what class does it. So
I need to go and look in the 'Control' object to see how the dependency
gets created. This is a definite cost of following SOLID principles.

The Single Responsibility Principle can exacerbates this. Sometimes I end
up reading through multiple classes to find out how something works when I
would naturally expect to just look in one place. Perhaps more technically:
the loose coupling we have achieved has sometimes been at the expense of
cohesion. That shouldn't be the case, but it sometimes happened. SRP is the
concept I struggle with the most when trying to follow SOLID principles.

As a contractor I see a lot of systems written by different developers and
I don't think that the complexity of understanding how this one fits
together is worse than those that don't follow SOLID principles. The only
real rules I can come up with are: that complex systems are harder to
understand than simple systems and; any system that you don't have in your
head right now is hard to follow and, as such, shit.

Given that, any programmer could look at the code in this project and make
a case that following SOLID principles has made code quality worse.
Likewise they could make the case that following SOLID principles has made
code quality better. There are no silver bullets in software development
and quite often decisions about 'better' or 'worse' code come down to
personal preferences, experiences, etc.

I am happy that following SOLID principles has lead to code which is easier
to change without introducing unintended consequences. It isn't perfect,
and it has some costs associated with it, but all things being equal I
would probably do it again.

I am absolutely certain that the SOLID principles push you toward a style
of coding which helps avoid a lot of problems that regularly crop up as
projects become more complex. That is not the same as saying that it is
appropriate for all circumstances, nor that it is the only way to address
these problems.

Understanding what problems SOLID principles address and how they try to
solve them will almost certainly make you better at writing software, but
that will be true for a large number of subjects. Dismissing them in
public, from a position of both influence and ignorance, does a disservice
to whole communities.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140428/000f67c7/attachment.html>