Books

Short works

Books : reviews

Martin Fowler.
Analysis Patterns: reusable object models.
Addison Wesley. 1997

rating : 2.5 : great stuff
review : 8 April 2001

Design Patterns have caught the OO community's imagination, and taken off in a big way. Analysis Patterns have taken longer to do so, partly because historical development of most new computing technique works backwards from implementation through design to analysis, and partly because analysis is harder to generalise than design: it is more domain specific.

Fowler has made an excellent first stab at documenting Analysis Patterns. He admits there is a lot more to do, but this book does provide a valuable starting point. I think its value lies in providing good examples of the kinds of patterns that occur at the analysis level, rather than that the patterns themselves are as reusable as the ones in the GoF's Design Patterns. So it provides meta-advice -- but it does that well.

My only, minor, quibble is the notation. I find it a little "noisy". Now that UML is available (it wasn't quite stabilised enough to be used when the book was first published) I would love to see a second edition using it. (It is interesting to compare the material on Association Patterns in Chapter 15 here, redone to some extent in Chapter 6 of UML Distilled.)

Patterns include:

Accountability
Modelling organisational structures: party, hierarchies, accountability, knowledge levels, operating scope
Observations and Measurements
Modelling clinical observations: quantity, conversions, measurement, observation, measurement protocol, time record, rejected observations, hyupothesis
Observations for Corporate Finance
Extending the clinical model for a new domain: enterprise segment, causal and comparative measurement protocols, range
Referring to objects
object identity issues: name, identification scheme, merge, equivalence
Inventory and Accounting
Tracking money and goods moving through an organisation: account, transaction, entry, posting rules, accounting practice, balance sheet
Planning
Planning, tracking and scheduling resources: action, plan, suspension, resource, asset, consumable, start and outcome
Trading
Buying and selling goods and currencies: contract, instrument, portfolio, portfolio filter, quote, scenario
Derivative Contracts
Problems of generalisation hierarchies: forward contract, option

Other modelling advice includes:

Packages
Visibility problems and trade-offs: architectural layers, mutual visibility
Layered architectures
A common way of structuring information systems: two-tier and three-tier, facades
Application Facades
Presenting only the relevant part of the domain model to an application
Design Templates
Implementation considerations
Association Patterns
Accosiative type, keyed mapping, historic mapping

Martin Fowler.
Refactoring: improving the design of existing code.
Addison Wesley. 1999

rating : 2.5 : great stuff
review : 1 November 2000

Do you think fiddling around with code to improve its structure it is time well spent, or just a waste of valuable effort keeping you from coding new functionality? After reading Refactoring, you should not only believe the former, but also know when to refactor, which refactorings to do, and how to refactor safely and productively.

This is a very nice book. An introductory section explains why refactoring is a good idea, why it saves time and effort in the long run, and when and how to do it. But the meat of the book is a series of small refactorings explained in detail. Each individual refactoring would make only a small improvement to the code, but the cumulative effect of many can be a massive improvement in structure, yielding comprehensible, maintainable, extensible code. The effect is cumulative, so even a small amount of effort can give a valuable return.

What I particularly like is the very disciplined approach Fowler takes to each refactoring. He not only describes the change to be made, but also gives a step by step process for effecting the change, in a way that means any mistakes made are relative small, and are detected as soon as possible.

Although all the examples here are in Java, the exposition is so clear there is no difficulty translating the approach into other languages. I've been trying it out successfully on some Smalltalk that needs a make-over.

I've always fiddled with my code (and other related documentation) to improve it. Now I understand how to do it in a much more disciplined and structured manner. And it was fun learning that.

Kent Beck, Martin Fowler.
Planning Extreme Programming.
Addison Wesley. 2001

rating : 3 : worth reading
review : 16 March 2001

Extreme Programming is a new way of building the right software, and building it fast, to a high quality. It's been tried on real projects, and it seems to work (it does require the development team to be relatively small -- ten or so programmers -- so no silver bullet yet for the more humungous software developments).

Whereas Extreme Programming Explained concentrates more on the actual coding side, this volume covers more of the client involvement, planning, estimating, and management aspects (and does assume you are familiar with the XP concepts described in the former book). Those are not always the most exciting of subjects, but the authors' clear and refreshing style makes this interesting, and makes the whole XP process sound terribly plausible.

Inspirational. I now want to rush out and join an Extreme Programming team. And I'm not even that fond of coding!

Martin Fowler.
Patterns of Enterprise Application Architecture.
Addison Wesley. 2003

Martin Fowler.
Domain-Specific Languages.
Addison Wesley. 2011

rating : 2.5 : great stuff
review : 26 September 2011

A Domain Specific Language (DSL) is a small special purpose programming language designed to express a specific small problem, or to perform a specific constrained task, and no more (there is a tendency, due to feature creep, for any DSL to become a Turing-complete language; this should be resisted). We used to call these "little languages", and they are quite prevalent: think of Unix utilities like yacc, lex, awk, sed, make, and pic, and today's GraphViz, and even LaTeX (although it's not that little!). A DSL can greatly help developing, configuring and using certain kinds of software application, and can help communication with the domain experts. Many developers don't know about DSLs, however, or if they do, don't know how to implement them.

Now there is no excuse. This is another excellent book on software design from Martin Fowler. Here, we see how, why, and when to use a DSL in your software project. The book is structured as an introductory section (~140pp) of background and tutorial material, followed by a comprehensive pattern language (~430pp) for building your own DSLs. I confess I have read in detail only the first part, and skimmed some of the patterns. I would read them in detail when using them in anger.

Even thought I already knew about little languages, and how to implement them, I learned a lot here about the rationale and structure of such approaches. A must for any serious software developer's bookshelf.

Martin Fowler, Kendall Scott.
UML Distilled: brief guide to the standard object modeling language: 2nd edn.
Addison Wesley. 2000

rating : 2.5 : great stuff
review : 27 March 2001

What a super little book. This could easily be called "UML in 2 hours" -- which is about how long it takes to read. But this is not just a whistle-stop tour of the notation. Fowler give solid pragmatic advice, in his usual lucid readable style, how and when to use each piece of the notation in analysis and design -- and, just as importantly, when not to use it. There's more good solid advice and guidance in here than in many of the larger doorstop-thick tomes.

Martin Fowler.
UML Distilled: brief guide to the standard object modeling language: 3rd edn.
Addison Wesley. 2004

(read but not reviewed)