This article is just so biased and full of odd opinions. "If your Java code has Date date = new Date(); buried in its guts, how do you set it to a known value

This article is just so biased and full of odd opinions. "If your Java code has Date date = new Date(); buried in its guts, how do you set it to a known value you can then compare against in your tests? Well, you don't. So what you do instead is pass in the date as part of the parameters to your method. You inject the dependency on Date. Yay, testable code!" Seriously? I've never seen things done in this way, ever. The correct way is to have a TimeSource interface and forego the direct use of Date. Simple. At this point it feels like the author's premise of the article has been invalidated. I don't like using the terms DI or IoC. I prefer to talk about "composition" and "componentisation". Because those are the real goals. Testing is almost a secondary concern in this regard, it is just a nice side affect and bonus of writing well designed software. The primary reason for designing your software in the style of composition and componentisation is for the separation of concerns and the achievement of all the SOLID principles. But let me guess, Ruby hipsters think those are bad too huh? As an interesting note, I once went to a Hacker News meetup in London and not a single one of the Ruby developers I spoke to even knew what DI or IoC were. Most didn't even know what static typing was either. Or even type inference. This is not really a good sign of a healthy community.