<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

I'm wondering what those who were at RailsConf and listened to DHH's<br>
keynote - or have watched the video:<br>
<a href="http://www.justin.tv/confreaks/b/522089408" target="_blank">http://www.justin.tv/confreaks/b/522089408</a> - thought about his description<br>
of dependency injection making code worse?<br></blockquote><div><br></div><div>tldr; somebody on the internet was wrong and I am outraged about it.</div><div><br></div><div>It took me a while to get through the video, I think mostly because it was a crock of shit.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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 (<a href="https://github.com/jcinnamond/lawyer">https://github.com/jcinnamond/lawyer</a>) but this is ultimately both inadequate and somewhat perverse.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div></div></div></div>