author : Martin Fowler

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

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.

• The Refactoring home page online catalog contains summaries of the refactorings in the book, additional information, and new refactorings

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!

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.

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.