April 6th, 2015
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: email@example.com
I have been reading Java Programming Interviews Exposed.
I never understood these “job interview” books before. Who can get ready for a job interview by reading a book? Surely that’s just cheap marketing by the publishers, who prey on developers insecurities?
However, I’ve decided I like this book. Not for job interviews — it sucks for that. But as a broad overview of the Java eco-system, it is perfect. It’s got a little about serialization, a little about dependency injection, a little about designer patterns — unlike those books that try to be comprehensive, this is just a summary of things. For someone like me, who doesn’t do much Java programming but who needs to understand the Java eco-system because I occasionally interact with it, this book is a nice overview.
Anyway, on page 250 is this amazing sentence:
“One concern with using a plain-text XML document for constructing Spring beans and defining dependencies is that you lose the value of compile-time type checking; any issues such as using the wrong type in a constructor, or even the wrong number of arguments in a constructor, are not found until the application context is constructed at run time.”
Wow! So you go through all the pain and burden of dealing with Java’s verboseness to get the safety of compile-time checking, then you throw that away so you can get dependency injection which will hopefully give you a small amount of the composability that a Ruby programmer, or a Clojure programmer, or any kind of Lisp programmer, would simply take for granted.
The book emphasizes that if you have XML configuration for Spring, then you must have a good suite of integration tests, which is exactly what a Ruby programmer would say, and a Ruby programmer would say that you don’t need compile time type checking if you have a good suite of tests — and apparently any of use of Spring used to be an admission of that from the Java world.
XML gives you strings, which perhaps match a class name. Using types rather than strings is one of the main reasons to use a language that is checked at compile time. They strings would only be checked at run time.
Apparently things have improved with Spring 3.0, which now allows the config to be written in Java instead of XML. The irony of this, of course, is that you now have a new source of potential bugs: the Java code that will configure your dependency injector. Considering that the most important goal of dependency injection is to separate configuration from use, there is some irony in using Java to configure the system that will allow your Java to be independent of your configuration. One has to wonder how far down that rabbit hole are intelligent people willing to venture, before they stop and ask themselves if a completely different approach might offer an easier way.
And this is from page 254:
private Dictionary dictionary;
Note that this field cannot be “final” anymore. The Spring application context will access and set this field after it has been constructed, using reflection.
Amazing. So we also need to give up on “Favor immutability over mutability”. To get dependency injection, we must give up most of the “best practices” of Java?Source