5 ms·
I think most of you are missing the point. I think the example DHH used should be interpreted as calling post.publish! is easier than post.publish!
by wyuenho 14y ago
I think most of you are missing the point. I think the example DHH used should be interpreted as calling
post.publish!
is easier than
post.publish! Time.now
Since when you publish, the time of publication is the only value that make sense. Now, you can argue that you can set a default argument to Time.now, but that's weird code that only make sense if you need to supply a value other than Time.now, which you will only do in testing, so the code in DHH's example is optimal.
The point of DHH's blog post is, in a flexible enough language like JS, Ruby and Python, you can still test pretty much anything without DI. I honestly don't know any other reason why one would want to use DI other than making Java testable. In fact, you don't even need that in Java anymore because you can use Mockito these days and it can mock private stuff.
The stupidest reason I keep hearing over and over again is DI makes it possible to change an implementation at runtime. Wait what? Don't you have to change the application.xml file in Spring and restart the app? AFAIK there's nothing in Javaland that lets you listen to config file changes and then magically reconfigure the app context and make a copy of said context as a thread local in every new thread. Correct me if I'm wrong please. Even if there was, what magical alien land would require such a "feature", and such feature is so important that requiring your entire code base to be littered with all these indirect abstractions acceptable?
- Xylakant 14y agoDI to swap out an implementation at runtime is an extreme edge case, though "runtime" may mean "the app can determine at startup which implementation makes sense". If you want to have a look at a nice usage of DI, peek into the source of Elasticsearch. You can swap out pretty much any relevant part of the implementation. You can for example change the HTTP acceptor to provide authentication [1] or add SSL [2] So there are cases where changing the implementation makes sense. [1] https://github.com/Asquera/elasticsearch-http-basic https://github.com/Asquera/elasticsearch-http-basic [2] https://github.com/Asquera/elasticsearch-ssl-transport-plugin https://github.com/Asquera/elasticsearch-ssl-transport-plugi...
- wyuenho 14y agoFor which any simple configuration mechanism will do, and as long as you stick with coding to the interface, the problem is solved. So while technically this is called DI in Java, it's simply code taken as granted in many dynamic languages because of duck-typing. So yes, this is totally valid use case, but one with no need for a DI container in dynamic languages to solve.
- thelawal 14y agoFirst a DI container is not a necessary to do DI in any of the discussed languages. This is shown by the fact that you describe using duck-typing as method of doing DI in Ruby.
- laureny 14y ago> The stupidest reason I keep hearing over and over again is DI makes it possible to change an implementation at runtime. No, DI is about setting up your application at start time, not at runtime. Configuration frameworks only cover a tiny fraction of this problem (basically by forcing you to pass a giant "Config" object everywhere). DI generalizes this process by making the information passed around more granular.
- mrgoldenbrown 14y ago>the time of publication is the only value that makes sense. Which time of publication? The time on the database server? the web server? The client's computer? What time zone? There is probably only one choice that makes sense to you, but I have spent too many hours dealing with bugs resulting from different people having different ideas on which one is the best one.
- wyuenho 14y agoThere is only 1 time acceptable - the ISO-8601 or equivalent time of publication in UTC, under the highest resolution you can get. Format to whatever you need on display. Give an option to the user to adjust the timezone in which the user agrees with, by default the user's timezone, if you know it a priori. All your servers should use the same time server to sync time.