Amazon reviewer's opinion on the Title of "The Object Primer"

Hi Mr.Ambler, I've read the following portion of comment from one of the reviewers at Amazon. Could you please explain why you titled the book as "The Object Primer"? Or is it just a personal opinion on the title of the book? Thank you...

The main title of the third edition, The Object Primer, is misleading. This book is mainly about agile model-driven development, which is part of the subtitle. A better title of this book should be The Primer of Agile Model-Driven Development. This book does not teach you very much about object itself. Chapter 2 gives you a review of object-oriented concepts. If you are new to OO, such brief coverage will not help you very much. This is not a book that teaches you UML either. UML 2.0 is used throughout this book in straightforward cases. If you are new to UML, you have to read other books first.

To tell you the truth I wanted to change the title to something like "The Agile Primer" but the publisher wouldn't let me. The focus of the book is on a full lifecycle approach to agile software development where modeling is a key component of that. The book covers a wide range of techniques, including all 13 of UML 2 (I believe it's the first book to do so, and I know that it's one of the few to do so). Yes, the book presents introductory overviews of UML 3 diagrams, as well as over 20 other modeling techniques. The goal is to show you that you have a wide range of techniques available to you, including the 13 of the UML. I go into the same level of detail, for the most part, as UML Distilled although cover a lot more ground. UML Distilled is a great book, but it won't give you the skills you need to actually model a real world application. For example, does your application include a user interface? Business rules? A database? I cover how to model these aspects of your apps, plus more. UML Distilled doesn't. Perhaps a better name for the book would have been "Agile Models Distilled", who knows?

I have to disagree with the person when it comes to his comments regarding the introduction to OO material -- it's the topic of chapter 2 and frankly it's pretty solid. It's been slightly updated from the second edition, published in 2001, which in turn was a slight update from the first edition in 1995. Frankly, how many people these days really need an introduction to OO anyway? It shouldn't be much of a shock that I didn't focus on that material anyway.

Frankly, how many people these days really need an introduction to OO anyway? It shouldn't be much of a shock that I didn't focus on that material anyway.

I would disagree with this statement. I recently conducted a bunch of interviews for a few requirements that I had in my company and was troubled to find that most of those I interviewed were able to rattle implementation details of object-oriented concepts (like how to declare abstract classes and interfaces in Java) but failed when I probed them with some pure OO concepts. They could answer in part why one concept should be chosen over another (say, an abstract class over an interface), but were not able to give a satisfactory explanation.

None of them had an idea about some of the basic design principles (as popularized in Robert Martin's book, which, I must admit, I read recently).

I think such a knowledge is a bit dangerous. With tools coming up every day (open source and non-open source), people seem to be focusing more on tools rather than the basics. It's like constructing a state-of-the-art building with a weak foundation. [ November 03, 2004: Message edited by: Sathya Srinivasan ]

I can echo Dirk's/Jeff's experiences. It's surprisingly rare to find a fresh college graduate who actually knows his objects, not to even mention patterns. Then again, it shouldn't be such a surprise considering that you simply can't really learn certain things (just) by reading books.

I can't recall how many times I've encountered people who attempted TDD but somehow ended up with a soggy mess of code covered by few tests. Yet they think they're doing it as they read in the book.

Until you actually see what we really mean by "tiny steps," you're probably going to be doing things at too large a granularity. I've done so many demos where people said, "oh! that tiny? Do you really program that way?" To which the answer is, "yes, and my steps are often not small enough."

And even then, 5 minutes after they see it demoed, and I ask them to code the same exact thing, I see stuff like:

And that is a complete test to them. Moral of which is, many people don't learn anything right the first time, from books or from any source.