For the past few years I began to doubt whether my understanding of the craft was even correct anymore. So many code examples in so called expert books are untestable procedural junk I couldn't imagine what had happened. Design patterns and unit testing seem to have lost their place in the world. Servlet and JSP books have always been crap that way but now books on SOA and the like technologies are that kind of junk code.
It was refreshing to find a book that emphasized the craft of coding - tests, reusability, comments, logging, decoupling, dependency injection, small methods, design patterns and so on. These aren't rocket science and they should be second nature to developers by now.
I breathed a sigh of relief when I read this book.
Having said that there are a few problems with the book. The author mixes programming paradigm terms too promiscuously. For example, he makes extensive use of Java code and continuously refers to "functions" and "modules". In a book about clean code that should be cleaned up.
The author shows a misunderstanding of JavaBeans and really should rewrite his somewhat snarky comments. His example of a JavaBean, for example, shows a list of Strings being passed in on the constructor and the class has no setters. A JavaBean by definition must have a no-arg constructor. His example had no setters (which is OK for non-mutatable fields). If that was the intent, however, the fields should have been final. Did he mean POJO? He puts this in a chapter on DTOs wherein he talks about data structures. I don't know how many times the fact that I was using a getter/setter saved me grief when compared to using an exposed field. Changing the internal field type based on some new requirement is a good example of how it can help. While the setter may initially look like little more than a pass through method for the "OO purists" -- bah, humbug -- it can end up saving rework of a large number of classes. It allows for overloading the setter for handling new types if the requirements change. If error conditions are determined that can be detected at the setter or getter level, the fact that one has the data structure wrapped has just saved a lot of headache. The distinction made between data structure and object in this sense is specious. These JavaBeans are generally little more than protective covers for the data and do little more than set/get the data. That all appears superfluous until it bites you. The very fact that they permit further modification to meet on-going challenges during coding shows why they are used instead of hanging fields out publicly and why they are more than just data structures in drag.
Perhaps he should also look at the event properties mechanism that is available for use with JavaBeans as well. There certainly are valid criticisms of JavaBeans, unfortunately the book misses them by a long way.