Compared to bicycles and shapes, this book is a step in the right^H^H^H a different direction in that it is data-oriented rather than object-oriented. Rather th

Compared to bicycles and shapes, this book is a step in the right^H^H^H a different direction in that it is data-oriented rather than object-oriented. Rather than make the claim (as they do in the introduction) that other textbooks are doing it wrong, I would have prefered to see acknowledgment that different tasks call for different approaches, and highlight that the data-oriented design presented here is usually left out of other texts. Giving examples, as they do, of tasks where the goal is simply to store and present data, it is only natural that a data-oriented design is what shows up. That does not mean that there are not programs whose job is to act on and manipulate data. But. Fundamentally, designing classes upfront is simply the wrong way to go about it. The argument may be made that the end result (I now know what good classes look like) justifies the method, but I disagree. It is the journey that is important, not the result. The students will not remember what a good jogging journal class hierarchy is. They will remember how to design classes on paper. In my experience, classes hierarchies written on paper or on fancy UML software, are bound to be "wrong". This is a Bad Thing. UPDATE: In fact, any tutorial about how to design classes that does not describe an iterative process, and make use of all the refactorings built into Eclipse or IntelliJ, is guaranteed to fail to teach kids what I do every day I program java (or C#).