Analysis Patterns: Reusable Object Models (Object-Oriented Software Engineering Series)

The first problem Fowler broaches is a patient's weight and he states, correctly I'm sure, that most programmers would just make weight a class property and make it be of type integer. But there are problems with that approach. First one is the issue of units. If you make it an int you are assuming that it is just a count of pounds. What happens if you want another measure? Furthermore, what happens when someone asks where the patient's weight has gone in the last month.

From this point of departure, many issues are taken up. For people who have grappled with OLAP before and know something about dimensional models, it will seem as though he is trying to make an operational into an analytical model, which experience has taught us is not good. But, in fact, there is sanity to Fowler's approach.

Personally, if he ever does rev this book (read on his site that he is thinking about it), I wish he would consider writing a section that attempts to hide the observation elements and seamlessly map them back into the object model. Having a separate class keeping track of what the weight of a person represented by another class is does ultimately seem to undo the objectness of the model, but that's a minor nit. Definitely a book that I've returned to many times.

As two readings of <i>Design Patterns</i> took my OO knowledge from infancy to adolecence, <i>Analysis Patterns</i> will take you from adolecence to adulthood. Fowler's work does not put together patterns from the <i>Design Patterns</i> book, but takes its time to decompose actual application domain concepts to applicable object models. It will then be up to you to use your knowledge from <i>Design Patterns</i> to create mechanisms that support properly modeled business concepts as <i>Analysis Patterns</i> describes.

If you like OO modeling and design, but are wondering how better to apply your modeling concepts, Fowler's book is something you will definitely benefit from. However, make a pot of coffee per chapter-this book is very dense with concepts.

Fowler ends <i>Analysis Patterns</i> with some more easily read chapters on application design on a larger scale. You've heard of "n-tier," his discussion of the concepts of "n-tier" at the end of the book are possibly worth reading first.

After reading this book-and understanding it's motivations-you will never again be tempted to take "innocent" shortcuts in your application design. You will not be motivated to use "Strings" for "measurements" or "doubles" for "distances." You will look upon your peer's object designs either with a new understanding that they know that going the distance with their object model is worth it-and you won't demand they dumb down their design ever again-and you'll likewise gain intuition about where a simplistic business domain model is going to fail.

This book forms a good follow-up to the Gang of 4 book.