Customer Reviews & Comments
I like the Head First series, and even Head Rush, for its innovative and fun approach for introductory software topics. I've had small concerns on all of them but I have never been as ambivalent as I have for this book. I know a big part of this problem was that it was rewritten expeditious (I am still not sure of the reason why) and it shows throughout the book with spelling, logic and code errors. You can tell that the first chapter was rushed. There are several spelling and programming mistakes. The most egregious is where they ask you to look through some code to find what "FIRST" you change and then they answer that question with a much smaller problem (the main problem was they forgot to add a return statement (pg.5) and they write about the inconsistency of using String based searching). It has also been mentioned by several reviewers of the use of the method name "matches" which only makes sense for regex not for an equals operation. I also did not like the search example (how can you not think of price in a search?). The best part of this chapter is the mantra that should be practiced by many engineers: "Make sure your software does what the customer wants it to do." The next few chapters are definitely better (though still some spelling mistakes). They are a good read for beginners and intermediate programmers on gathering requirements, change of these requirements and analysis. The ideas are a bit simplistic though it is good to get many programmers used to the idea of UML and use cases and using them to drive requirement gathering and textual analysis. Intermediate and advanced readers familiar with use cases will gain more from reading Alistair Cockburn's "Writing Effective Use Cases" (or will already have read it) and for further UML reading should go with "UML Distilled" by Martin Fowler. When the book gets back to design I see some problems with the coding. The designer has this bizarre idea of abstracting all properties (under the guise of "encapsulate what varies") into a Map attribute to lessen the amount of subclasses for instruments. While initially this may seem a good idea it gets rid of all type-safe coding (you can now safely assign an instrument type to a backwood for the instrument), you cannot have behavior from the instruments (this is mentioned in the book) and if you put a property with one letter misspelled or capitalized out-of-place you now have a bug, one that you might have trouble finding thereby increasing maintenance costs. Too much flexibility makes the code ambiguous. After design, the studies get to solving really big problems, architecture, design principles, and iterating and testing. These chapters I enjoyed much more especially the chapter on design principles with the beginning mantra that "Originality is Overrated." This chapter goes over basic principles such as OCP (open-closed principle), DRY (don't repeat yourself), SRP (single responsibility principle) and LSP (Liskov Substitution Principle). Then the book last chapter (the ooa&d lifecycle) sums the lessons in the book in one large (somewhat contrived but these type of examples always are) program for the Objectville Subway. Then two terse appendixes dealing with ten additional OOA&D topics and OO concepts should make the reader realize that this book is just an introductory sliver of what needs to be learned for a sagacious software acumen. This book is useful for programmers with a bit of Java (or C#) knowledge who want to get a good overview of OOA&D. This book is useful because it teaches important OO vernacular and a simple holistic approach to iterative development. If the book did not have a "quickly done" feeling, better design and fewer mistakes I would have liked this book more. This book is a good candidate for a second edition. If you want a more thorough explanation of these topics I recommend "The Object Primer" by Scott Ambler as one of my favorite books for a good introduction to OOA&D.