Just A Summary

Piers Cawley Practices Punditry

Applying design patterns unconsciously 1

Posted by Piers Cawley Mon, 21 Aug 2006 07:33:00 GMT

I just realised something about the workings of new style Typo Sidebars: it’s just an application of the Parameter Object design pattern; the render_sidebar helper method takes a Sidebar parameter object and produces a chunk of HTML. The fact that we persist the parameter object using ActiveRecord is almost beside the point – the persistence is more important to the  render_sidebars method than anything else.

Old style sidebars couldn’t really be called an application of any design pattern. Maybe that’s what bugged me about them, they lacked the Quality Without a Name. I’m not sure that the new sidebar architecture has the Quality either, but it’s much nearer to having it.

When I was learning to play Go someone told me that it’s easier to remember professional games than those of amateurs because the moves in a professional game are generally more ‘right’ than those of weaker players. To a good go player, the ‘right’ move has an obvious purpose (or, more likely, purposes). Bad moves don’t.

Maybe something similar applies to code. In good code it’s clear what each piece does – maybe it can be seen as an example of a design pattern, maybe not – and the pieces relate well to each other. In bad code, the intent and relationships are muddied. 

Do Design Patterns Help?

Continuing the Go analogy, Design patterns can be likened to joseki – ‘standard’ patterns of good play in the opening of the game. It’s useful to know them, but what’s really important, and what takes time, practice and deep study to get good at, is using and adapting them well in the fuseki – the opening and its wider context. You can play a ‘perfect’ joseki in one little corner, but its influence radiates across the board and if you don’t pay attention to what that influence is and use or adapt it well, you’re screwed.

I think the analogy to the use of design patterns in programming is fairly obvious. Don’t you?

'Extreme Building'

Posted by Piers Cawley Sat, 30 Aug 2003 09:54:00 GMT

Our experience as contractors, engineers and architects during the last 15 years has proved one thing over and over again: The things placed on drawings are inevitably – always – wrong in many particulars. Drawings serve as an important rough sketch of something that will be built, but must be executed with constant attention to room shape, light, wall and ceiling detail, openings – above all to the feelings which arise in each place, in the construction, as it is taking shape. These feelings are too complicated to predict and cannot be predicted. When a building is built from plans that are conceived on the drawing board and then simply built, the result is sterile at best – silly most of the time – and sometimes unthinkably bad. This is something familiar in virtually all large buildings that have been built since 1950. It is inevitable, given the process of construction used to build them. And it is inevitable that this process must lead to unsatisfactory results.

— Christopher Alexander, Gary Black & Miyoko Tsutsui The Mary Rose Museum

Another installment in my ongoing series of reviews of books that Amazon will take an age to deliver.

The Quality Without A Name 1

Posted by Piers Cawley Tue, 29 Jul 2003 06:06:00 GMT

There is one software patterns book I've read that has The Quality Without A Name in the same way that ??A Pattern Language?? does. That book is ??Smalltalk Best Practice Patterns?? by "Kent Beck":http://www.c2.com/cgi/wiki?KentBeck. ... ??Smalltalk Best Practice Patterns?? is a complete pattern language, something that I've not seen achieved in any other software patterns book (though Martin Fowler's ??Refactoring: Improving the Design of Existing Code?? gets pretty close.) It's easy to read; full of practical wisdom from someone who knows their stuff and who can explain it phenomenally well.



Just A Summary