What's interesting is the amount of territory that Odell covers in this book. These aren't beginners' issues, lots of them go straight to the heart of OO design. What does aggregation really mean, for example? How can companies ensure high-quality, maintainable software products in the presence of ever-changing and often inexperienced developers? What is the proper way to express the changes in an object's meaning over time? And finally, what is the methodology to end all methodologies?

Unfortunately, I found the writing opaque at times, and many of the proposals at odds with the lessons of my experience. In the opacity department, I would have liked a bit more description of just why a 'lattice' constraint describes a DAG. I could have done without understanding that state machines are useful "When user experts find that [state machines] are the best way to describe their system," with a similar tautology describing when they're not useful.

I was simply baffled by his support for objects with types that can change at run time. There is elegant theory behind the idea, but it's mostly a lab curiousity and for good reason. You could start with the difficulties in assigning an object reference to a variable, then changing the object type so it no longer matches the variable type. I'm quite happy with compile-time type checking, though. It means that whole realms of run-time bugs can't pass compilation checks, and saves endless annoyance. Anyone who remembers the BLISS language that implemented Vax/VMS probably still has nightmares about weak typing.

Although interesting to a point, the discussion of aggregation went beyond practicality. It was well into the realm of philosophical hair-splitting, but without the formal rigor that could have justified the fussiness. I guess that's what really bothered me all through - high-sounding discussion, without the serious backing needed for the points to make sense. Even his grand idea for a meta-methodology floated away into meta-meta-ness, without giving any clear idea about how all those round pegs and square holes could be resolved with each other.

Most of all, the ink on the book's page is frozen in time, and times move on. Many ideas that may have seemed novel or profound in 1992 have been overtaken by events. Although a few points remain interesting, today's readers have better ways to spend their time and money.

//wiredweird

Some of the articles are pre-historic from our frame of reference, but there is much in here that is excellent background material.

This book is certainly for a very advanced student. If you are just beginning, it's not going to tell you much. But if you are into graduate studies and need some good references, this is the book for you. I will probably read this book several times to get the ideas in it, but being a graduate student, I find it very helpfull. The author is very precise in his use of the venacular. Probably about 30% or so is really applicable to the software engineer, but the whole book is a great study in pushing the limits of OO modeling. Worthwile for the congitive person.