I’ve been reading Joshua Bloch’s Effective Java recently, and it’s quite a fine book: it’s one of those “best practices” books that divided into “Items” instead of chapters. I’d read a similer book a few years ago called Practicle Java, which served as a good intro, but it wasn’t quite as design minded as Bloch is.
Design mindedness is exactly what makes the book interesting; this is opposed to simply “how to do it” books, which are great in their own right.
For example, quite a bit of Bloch’s tips are driven by how people will try to sub-class, or wrongly use, your code, and vice-versa. This leads to rules of thumb like, Item 14, “Favor composition over inheritance,” in which the point is made that, really, inheritance is a complicated mess to get into. To cite only one potential problem, future
implementations of the super-class in question might change, messing up how you thought the super-class worked, making your sub-class depend on, now, non-existant methodology…or something like that.
In one extreame of the Perl world, it seems, this kind of “defensive coding” is poo-poo’ed in favor of the spirit “let ’em fuck ’em selves.” Taken too far in the Java world, you probably end up with something akin to a smarter
doozer’s Tommy Hilfiger programmer. Regardless, it’s fun readin’ to get a different slant on how to go about coding.
Anyhow, it seems like Effective Java, along with Ye Olde Design Patterns, and a good Java reference book (I prefer the meaty A Programmer’s Guide to Java Certification) would make for a fine Java bookshelf…just in case you were wondering what I thought…
(With this post, I hope to achieve top slot for the Google search “Tommy Hilfiger programmer”…)