“Design Patterns” Aren't (2002)

Alexander is talking about 'spaces' in buildings, how they take shape, how they interact, and how they serve the greater style and purpose intended by the master architect to serve the lifestyle of the resident. Here design focuses on the end product and how it will function for the user. These design patterns have nothing to do with how the building was constructed or the experience of the tradesmen who built it.

In contrast, the GoF book did not talk at all about the final software end product, but only the process of building it. The emphasis is entirely on the tools of the tradesmen and encouraging their proper use and re-use. Such design patterns do not reflect the user requirements or even the architect's high level design of the software product, much less serving the user experience in a consistent purposeful way.

However it seems to me that Alexander's approach to patterns could have been adopted in the software domain, but I think that would have looked a lot more like Jef Raskin's style guide at Apple which encouraged developers to adopt a common holistic yet systematic approach to Mac software so that the user experience was served. I think Raskin wanted apps to fit together the way that rooms in a well designed house flow from one to the next -- something Alexander would endorse, I think.

Another variant on design patterns in the software that might have worked well, at a level that might have bridged Raskin to the GoF, could have been Alan Kay's model for objects. The higher level conventions for components and behaviors that Kay espoused might have made for an interesting basis for patterns like those of the GoF. But without Kay, much less Raskin, the very modest ambitions of today's notion of software design patterns led nowhere but software reuse -- an inauspicious end to Alexander's vision, IMHO.

i'm going to go with the notion that you're genuinely curious.

I worked on a project with grids, an editable table like an excel sheet. Each grid, row, column, and cell could be styled. Font as Arial, Comic Sans ...; Color as rgb; padding top, left...; background color as rgb; Alignment as left, right or justified; format as freeform string, integer, float money or regex; decimal separator as . or , ; thousands separator as . or ,; and a whole bunch more.

The first cut just naively associated a style struct as part of each cell's data. Several customers complained that grids were very slow to start up, a few complained that they were running out of memory. They were using very large datasets for the grid, and the naive implementation wasted a lot of time on initialization, and a lot of memory on duplicate representation of style.

In retrospect it was a stupid mistake to make. We'd only tested against small amounts of data on relatively fast machines. Customers were using millions of rows.

The solution we went with was the aforementioned pattern. it saved a ton of memory and a ton of time avoiding all of that initialization. There were a few rounds dealing with smart lookup of style based on cell, row, column, and overall table.

My c++ is rusty, but i'm a little baffled by your confusion. Iterating over data structures in a uniform was was kind of a big deal back in the day. IIRC, implementing preorder, inorder and postorder iterators for a binary tree was homework. Have iterators fallen out of fashion?

I don't have a peer reviewed paper paper indicating flyweight is helpful. I don't have a peer reviewed paper saying multiplication is better than looping over adding m to itself n times. It's just better.

Some of them are mostly stupid, ala singleton. Of course even stupid singleton is a nice place to stick environment variables, because they are globals. I never thought decorator was all that great. I really like composite, but i like tree representations that i can recurse over.

If i had a scale, where you could place code on one side, and a design pattern on the other side, and it would balance if adding the design pattern was worth it, i would give it to you. To my knowledge, no such thing exists.

If you have questions, i'll try to answer. here or jfoutz at gmail.

But these pattern catalogs present a risk of seeming complete. To believe that you're near completion on a list of patterns in any field is utter hubris. Alexander's own hubris at having discovered objectively "correct" architectural styles led him down a path towards obsolescence while the rest of the architectural discipline moved on. The hand wavy "scientific" surveys Alexander conducted wouldn't pass a basic social science methods review these days. Pseudoscientific methods of assembling anecdotes or interviews from small samples that don't control for sampling bias will always result in some interesting insights that can't be reliably generalized beyond the narrow scope from which they were gathered. That's what both of these pattern languages are. At best they are a handful of neat ideas that other practitioners can reuse. But these are not some sort of reliable canon. We're all going to have to do more rigorous research if that's what we want.

There might be another parallel in here about the fetishization of anachronisms. Alexander, who is an architect not a carpenter, goes out of his way to glorify hand-crafting things (literally avoiding power tools). Unless you're a carpenter who specializes in make "artisanal" works of art for wealthy patrons, I guarantee you'll enjoy the productivity gains of a pneumatic nail gun. So if you ever find yourself insisting that some old "pattern" is more pure at the expense of everyone else's productivity, double check whether your dogma is worth it.

TL;DR. Don't take patterns too seriously. Always look for new ones.