by Martin Fowler
foreword by Ward Cunningham
When I look at a software development project I look for experience. Does the development team have experience doing relevant work? Can they apply their experience to the objects they build? Unfortunately, the answer to these questions is often “no.”
A growing number of us in the object-oriented development community feel we have misplaced our collective attention for some time. We no longer need to focus on tools, techniques, notations or even code. We already have in our hands the machinery to build great programs. When we fail, we fail because we lack experience.
Martin Fowler has found a way to give us what we need: experience in book form. He has done for domain objects what Eric Gamma, et. al. did for implementation objects in their landmark work Design Patterns: Elements of Reusable Object-Oriented Software. Martin uses the familiar terminology of our nascent community, but in a different way. He uses the word “pattern,” for example, not because he’s duplicating or extending Gamma’s book (or any of the other new titles bursting onto the market). He calls his written form of experience “patterns” simply because that is what they are. In his work, he repeatedly found solutions to recurring problems, and discovered the pattern form in the process.
Martin Fowler easily could have written a book on object-oriented analysis. Luckily, he didn’t. Instead we have a book cataloging the result of analysis. Each chapter reports the conclusion of his (and his colleagues’) analytic efforts applied to common business problems. The domains addressed vary from medical record keeping to financial derivative trading, with several stops in between. Which chapters apply to you? Amazingly, they all do. Martin places each problem in a context, then offers a solution for that context. You will see familiar aspects in every context. You will recognize the problems. You will appreciate the results. And there it is: experience.
Finally, Martin writes in a personal style, relaying his thoughts and judgments. We feel his respect for his clients and colleagues, from whom, he admits, most insights arise. We watch him keep his distance from the vagaries of implementation while still preserving implementability, a tightrope walk that defies direct explanation. As we see into the mind of an expert analyst, we gain a lesson in the how-to of analysis that adds to our own store of experience.