Recently in Patternalia Category

I'd been of the mistaken belief that the term refactoring, while used in casual parlance during the 1980s, hadn't made it into print until the publication the seminal paper by Bill Opdyke and Ralph Johnson in 1990. Opdyke's 1992 thesis gave a more detailed account of this work.

Thanks to Bill Wake for pointing out this this fully-formed treatment of the style of program revision that came to be known as refactoring in his 1984 book Thinking Forth, by Leo Brodie. And right there, on page 181, is what is, to the best of my knowledge, the first published appearance of The Word itself.

Forth enjoyed a burst of popularity during the early 1980s, before the object boom. I still own a copy of Starting Forth. Alas, this is the first time I'd seen this treatment of program factoring in Thinking Forth.

Forth, of course, remains an ubiquitous part of our everyday lives, in the guise of a proprietary variant, Postscript, that hums along under the hood in so many of the world's printers (among other places).

A tip-of-the-hat to Leo, and the refactoring pioneers of Forthdom...

I came across this interview with legendary Code Hygienist Bob Martin, and want to bookmark it here before I lose it.

Among the highlights was an insight that test-driven development can gain suite-cred when sold by analogy with double-entry bookkeeping. I was reminded of the early PLoP conferences where a entrepreneur and rouge scholar Dan Palanza promoted the idea of double-entry bookkeeping as pattern that he was convinced has applicability beyond the domain of accountancy. It was gratifying to see Bob showcase this useful connection between it and TDD.

The discussion of codebase health metrics was useful too. Here's some information on the Braithwaite metric mentioned in the interview.

The San Franciso PostGreSQL Meetup Group will be host a presentation by Fred Moyer entitled Big Blue Ball of Mud tonight in Oakland.

I have no idea where the "Blue" came from. Adult content? IBM? The Democats? In any case, Mudheads Unite!

---

http://www.redhotpenguin.com/talks/npw2007/ball_of_mud.html || http://conferences.yapceurope.org/npw2007/talk/493

In what turned out to be a de-facto tenth anniversary observance of the conception of our epic spasm of pomposity Big Ball of Mud, I was asked to give my very first presentation of this work as a Google Tech Talk last month in Mountain View. The announcement for it read:

It went, well, God help me, something a lot like this:

Comments from LD || Referral from Best Tech Videos || วีดีโอพรีเซนต์เตชั่น Big Ball of Mud ที่ Google || Is your newspaper.com a big ball of mud? || soft wet earth || The $100MM Canonical Model || KLOCs and Golf Scores || Big Ball o' Mud: Code Tangles and Organizations

Mariann Unterluggauer reports here on the latest ruminations from peripatetic software visionary and Catfish favorite Richard P. Gabriel at the OOP 2006 Conference in Munich. Dick, whom it would appear is riding a sustained wave of popularity in Europe, summoned his inner Cervantes to deliver a talk provocatively entitled Impossible Design...

What's new here is that nothing is new here.

I used this phrase nine years ago to open an obscure spasm of pomposity that opened the Pattern Languages of Program Design 3 book to describe the patterns movement itself. But, in the spirit of that piece, I'm going to shamelessly recycle it here, because it fits Ajax, that trendy, breakout postmodern school of web application design, to a tee.

The fascinating thing about Ajax is that it is an amalgam of existing technologies that all date back to the twentieth century. It's what the Web 2.0 crowd might call a mash-up. Only the name is new.

"Ajax" is short for "Asynchronous JavaScript + XML". This moniker (not the technology itself) is the brainchild of a meme-slinger who calls himself Jesse James Garrett, a handle more redolent of saddle soap than household cleaner. Garrett rides for a high-end Bay Area Buzz Boutique calling itself Adaptive Path. Garrett makes no intellectual paternity claims for the ideas proper, only for the name and the description. His web essay, Ajax: A New Approach to Web Applications cites several know uses for Ajax, and lists some defining characteristic of this style of architecture. In short, his essay is really quite pattern-like, though I don't think he claims as much. He'd certainly be entitled to do so. In any event, Garrett's essay, by conferring a name on this otherwise ineffable architectural notion, has put both Ajax and "Ajax" (to say nothing of Garrett himself) on the map.

Sun, for its part, is cautious about embracing the Ajax handle, but is not coy about this school of design itself.

Indeed, it's not clear that anyone claims to have actually invented Ajax. Instead, ad hoc designs using these technologies, such as Google Maps, Flickr, and the like, have appeared and incrementally grown more elaborate, and more refined right under everyone's noses for the last couple of years. Such is the face of innovation in the 21st century.

Now, Michael Mahemoff has exhibited no compunction in calling a pattern a pattern. Ralph Johnson pointed out this website a few weeks ago for a forthcoming book on Ajax Patterns. It is tastefully rendered, and quite engaging. I commend it to the reader's attention.

if nothing else, Mahemoff's site has encouraged me to take a harder look at MediaWiki as a pattern cultivation tool (though I've yet to do so.)

A few thoughts on Ajax:

It should go without saying that like so much of "architecture" in the web services realm, Ajax is a Worse-is-Better poster child.

Ajax applications typically shift control of an application back from the serve to the client side using a client side "engine" written in Java script. This engine communicates asynchronously with the server using XML. The server side could be written using nearly anything, but typically is written in a scripting language like PHP, Python, Perl, or Ruby.

Ajax, it would appear, has as it basis the groundbreaking architectural premise that a local rendering engine that buffer's communication with remote servers can provide a more satisfying, more responsive interactive experience to the user than can websites without one. (There I go with that tone that may strike readers as a touch sarcastic. I assure you that I don't have a sarcastic bone in my body.)

Under the hood, Ajax is an unspoken triumph for object-technology. JavaScript, PHP, Python, even Perl: all OO.

Why XML? For one thing, as always, XML can effortlessly traverse that semi-permeable membrane, that blood-brain barrier, Port 80, and hence walk through firewalls that would impede other vectors for virtual matter.

Why Javascript? Why did applets fail, and JavaScript win? Why now? It would seem that Ajax is (also) a poster-child for Moore's Law, and rolling obsolescence. Sometime around the turn of the century, 1GHz machines were all the rage, and now, the trailing edge of this Moore's Law curve has reached this point. The Ajax phenomenon is driven by the trailing edge of Moore's Law. That is to say, one can pretty much assume everyone has at least a 1GHz machine, and Windows XP or equivalent OS. Furthermore, the browser wars have essentially assured us that the vast majority of users have Javascript on the client side.

Code that would have performed unacceptably under scripting languages like JavaScript, or PHP, or Python for that matter three years ago, will run just fine now. Finally, we are spending some of our Moore's Law dividend fruitfully on something other than GUI eyewash.

In 2006, we can assume that script code that would have taken a DLL ten years ago, or a JIT'er five years ago, will run fine as-is. We can assume that the typical user buys in at broadband, and that bloated XML packets will not clog his or her plumbing. We can assume that a browser that runs JavaScript is at least in the user's back pocket. We can assume graphics horsepower that would have dropped jaws during the Clinton administration. We can assume that a 60Mb IE RAM footprint will draw only yawns. We can presume that machines that run at mere Megahertz clock rates are headed back into the closet.

Of course, the same reasoning applies more or less to just about any "LAMP-based" design.

---

James Governor concurs that Garrett's is a pattern naming coup here. [Michael's Ajax Patterns Tag]

Thomas Jay Peckish II was asked to write the following biography for Ralph Johnson for the forthcoming Pattern Languages of Program Design 5 Book. Peckish really was in Louisiana at the time, on a fine Sunday morning...

---

Ralph Johnson was born in the Panama Canal Zone, the son of a missionary doctor. He grew up to be one of the object-oriented community's best known, and most effective evangelists.

During the '80s as an early, and often lone, voice in the software engineering wilderness, he was instrumental in launching a Smalltalk revival in the academic community. His early missives on object-oriented reuse and framework design are still read today.

In 1994, he collaborated with three other equally gifted, and inspired, evangelists to produce an enduring testament to the power of the object-oriented community's collective wisdom: Design Patterns: Elements of Reusable Object-Oriented Software.

Like his father before him, Ralph, too, is a doctor, having received his PhD in Computer Science from Cornell University in 1985. It was not enough that his book provided a roadmap, an inspirational vision, for code redemption. Dr. Johnson also set about the task of providing the instruments, the tools to help ailing code to get better. The first practical refactoring tools, and the underlying doctrine to support them, were first promulgated by Ralph and his disciples during the early and mid '90s.

Ralph lives in Champaign, Illinois with his wife Faith, his children Joy, Grace, and Caleb, and their dog, Shirley. He works at the University of Illinois at Urbana-Champaign.

--Deacon Thomas Jay Peckish II
Nicholson Rd. Church of Polymorphism, Baton Rouge, LA

I stumbled across, in the course of my customary World Wide Web Woolgathering this afternoon, upon these crib notes for all 253 of the patterns in Christopher Alexander's A Pattern Language...

---

More woolgathering: A City is Not a Tree, by Christopher Alexander. I'd never seen it until today, but it covers some of the same turf we'd attempted to cover in our paean to Piecemeal Growth a few years back. Alexander's treatment is, of course, considerably more elegant and comprehensive that ours. (Seriously, there is no comparison.)

---

One of the overarching themes of Catfish in the Memepool has always been intended to be the futility of the pursuit of classical originality in the twenty-first century. Catfish are, after all, the quintessential bottom feeders. So I checked, and discovered that A-List techie meme arbitrageur Clay Shirkey (a fellow whose compilations I enjoy, but am evidently behind on) had already raided this tomb. I learned this, in turn, here. I chased down Clay's citation, only to find him, in essence, briefly lamenting the same thing before embarking on his discourse on the content of this Johnson Administration Era (1965) gem. (This paper will be forty years old in May.)

---

A City is not a Tree (Alternate Source)

Our patterns reading group here at UIUC has been looking at a collection of patterns on Testing Automation by Gerard Meszaros. Today, several of the students who usually attend these workshops are absent, because they are home in bed instead, following marathon efforts to turn in machine problems for their operating systems course.

I’d been looking in on their progress for the last few days with the sort of avuncular amusement typically reserved for watching young bucks nurse their first hangovers. Having waited until the last forty-eight hours or so before their deadlines to finish, sleepless nights and a mad dash to the finish line were all too inevitably in their immediate futures.

Amazingly, this ritual has changed little in almost thirty years. I recall, perhaps with more pride than fondness, ultimately prevailing over almost identical assignments. In my case it was during the last days of the Ford Administration, in the old Digital Computer Laboratory across the street. These pups work in the fancy new Siebel Center for Computer Science, and even from home. Then, they were virtual memory system simulations. Today, they were file system simulations. The more things change…

If anything, the target programming languages today are worse. Pascal, despite, or more to the point because, of its limitations, exposed few pointer- and destructor- hell pitfalls than does C++. The debuggers and programming environments have improved, but less dramatically than some might think.

And yet, there was one major, glaring difference between then and now. And that is the use of test cases, and automated testing. Students now are provided with a set of tests, that, when passed, indicate that the machine problem is complete. Students are encouraged to write their own unit tests as well.

In thirty years, this is the one innovation that has changed this biannual ritual for the better. The amazing this is that it took no particular technical breakthrough to enable this to happen. We could have systematically written unit tests thirty years ago, had we thought of it.

I’d guess that automated testing cut at least a day off of the student's pain and suffering time for this machine problem (to say nothing of that for the graders).

The more things change … the more important it is to test them…

--BF, in a retrospective, though not particularly nostalgic mood…

---

Photograph (C) 2004, The Laputan Press, Ltd.

In nuclear engineering, a moderator is a medium that reduces the velocity of fast neutrons, thereby turning them into thermal neutrons capable of sustaining a chain reaction.
--The Free Dictionary

I couldn't have described the moderator's role better myself.

Danny Dig and I recently moderated a writer's workshop for a set of patterns written for Ralph Johnson's graduate software engineering course. We opened the workshop with the quip above.

Levity is, of course, an end in itself. But moreover, it serves several additional functions. It relaxed the authors, in this case, first timers all, and, more importantly helped to melt down any "stature gaps" that may exist among participants. Its very introduction sets a more informal tone, and offers the expectation that any attempts at posturing and pretense will be similarly dealt with.

Whether you are a student whose advisor wrote the book on patterns, an academic shopping his or her work before the best-known luminaries in his field, or a domain expert trotting out his or her first serious attempt at writing since high school, a writers workshop can be a genuinely intimidating experience.

A certain degree of irreverence is a great equalizer. I shudder to think of the alternative.

I'm mentioning this because disciples of Richard Gabriel's more aggressive, more didadic writer's workshop moderation style have made his approach all-the-rage on the patterns circuit of late.

Gabriel often turns the usually perfunctory pattern summary section of his writer's workshops into a quest for "the heart of the pattern". I can tell when a moderator has been drinking Gabriel's Socratic hemlock when he or she begins by demanding that I rip the pattern's beating heart from its chest and hold it high above the altar for all to see. Dick, by dint of meticulous preparation, experience, and raw animal magnetism can pull off the high priest pose; I'm not sure it's the best persona for most of the rest of us.

I've seen a variety of workshop moderation styles work. In a workshop where everyone is prepared, the moderator need do little more than direct traffic, the didactic functions being spread among elders and well-prepared rookies alike. Thoughtful color commentary is easier to come up with when you aren't calling the game.

It's possible to "teach" from any chair in the room, not just the moderators, moreover, not all of us ought to presume to be in the education business.

I like what Ralph has said about Dick's example having given us all license to do it our OWN ways. That's the example we should be emulating. We can't all Be Like Dick, though surely we can learn from him, but most of us could still do a better job of being ourselves.

There are a lot of ways to run a workshop that work. Moderation in all things is a virtue...

--BF, ...humor included. (drawn from a mailto:members@hillside.net submission...)

I came across a post by Ralph Johnson the other day about an ambitious new project being undertaken by legendary object-oriented methodologist Grady Booch. Here are a few thoughts about this enterprise, in no particular order:

This is a noble, eminently worthwhile, and potentially even monumental undertaking.

---

This will demand pattern mining on an industrial scale not heretofore seen. IBM is poised to become, in effect, the Peabody Coal Company of Pattern Mining. Properly executing such a programme will take a cadre of specialists with an unusual mix of analysis skills, domain expertise, organizational accumen, and programming knowledge. Oh, and a rich command of the patterns and sofware architecture literature as well. I have no idea whether Big Blue has an underemployed legion of such talent awaiting remobilization. Is this a New Deal-style WPA for pattern miners?

---

Kudos to Booch for recognizing the seminal role played by Bruce Anderson's groundbreaking architectural handbook workshops at OOPSLA during the early '90s in laying afoundation for the Gang-of-Four's subsequent efforts, and ultimately, this work itself.

---

Booch may find himself in a position to confirm or refute a conjecture that Joe Yoder and I made a few years ago to the effect that the mostly widely deployed high-level architecture out there, despite widespread claims to the contrary, is, in fact, the BIG BALL OF MUD. To do so, however, might require an impolitic degree of candor, as well as a degree of pick and shovel work beyond the envisioned scope of this effort. Alas, the path of least resistance will likely be to simply parrot each system's high-level brochures.

---

There is a danger here of allowing this handbook to turn into a coffee table book; of producing an Architectural Digest; of pumping out self-serving, mutually congratulatory puff pieces, rather than objective depictions of how the portrayed systems are really put together. It's easy to imagine an unholy alliance between consultant and client that extols the fictional virtues of set-piece paper palaces, rather than the hard fought victories won out in the trenches. My hope is that in their search for "inner beauty", the authors will strive to see beyond the two-dimensional cartoons and into intricacy and richness of the code itself.

It is said that a programmer who dies at the keyboard will be greeted in paradise by seventy-two versions, his for all eternity...
--Thomas Jay Peckish II

A number of us have put off following up on a fascinating, and
surprisingly productive OOPSLA Workshop from back in 2000, in
Minnesota.

Workshops -- Monday

Pattern Refactoring

I should dredge up my notes from this confab and post 'em...

5 September 2003
Friday
Death Valley Days #2

Recall that Ronald Reagan was one of the hosts of Death Valley Days…

An UP Observation: We are remoras on the Gang of Four barracuda. Only the GOF out-takes seem to have stuck:

EXTENSION OBJECT
EDITOR
TYPE OBJECT

NULL OBJECT
MVC/DOC VIEW

Three of these came from the Smalltalk world.

While there was some talk about the POSA patterns, they didn’t seem to make their way into the discussion all that much.

The test of a pattern is whether it really does

Do a GOF Talmud Page, to go with the GOF Thoughts shrine. Include Proxy Revisited, Null Object, Extension, Serializer, Type Object, Editor, etc.

The two observations above are from my 1997 notes. The following list is from the OOPSLA 2000 Workshop on Pattern Refactoring.

GoF Outtakes

1. Null Object
2. Abstract Class
3. Interface Class
4. Boilerplate Class
5. Type Object
6. Reifaction/Objectify
7. Serializer
8. Extension Object
9. Product-Trader
10. Bureaucracy
11. Role / Extension
12. Property
13. Whole Value
14. Abstract Object
15. Curried Object
16. Factory Object
17. Natural Object
18. Tools and Materials
19. Layer Object
20. MVC
21. Master-Slave
22. Publish-Observer
23. Presenter
24. Multiple Representations

Interpreter -
Abstract Factory -
Factory Method - -
Template Method - -
Decorator - - -

Iterator broadened to Streams

Services
Provides Information
Structures
Coordination
Controlss
Interfaces

Problematic

Proxy
Wrapper
Façade Adapter Decorator Bridge Proxy

Double Dispatch
Delegation
Abstract Class

There's been a thread in comp.object about refactoring to MVC. The intent is to tame a purported Swing UI monstrosity, and instead to move towards MVC by-the-Hoyle.

Hmm. I'd have scored Swing as being well within the broad outlines of MVCs intent penumbra, if not umbra, already.

The broader, more interesting question is why the Swing solution is regarded as a Frankenstein. Those components mesh better than most I've seen. Swing is a modern, third-generation (nth?) design / architecture. If programmers regard it as hopelessly Byzantine, what hope is there left? What's the problem with Swing? Is it so broad that its hard to learn? This could be so. My experience with it has been the learning curve is something well short of gentle. Issues like layout intrude far to early for my taste. Few components work out of the box. Is it capriciously arbitrary? Is it that the elements integrate in something short of a "seamless" fashion? They do seem to demand arbitrary trowel work, and more mortar, than one would expect of a framework that aspires to being the substrate for pre-fab solutions.

Is the problem that Swing had to be rolled out essentially finished? It had to emerge full-grown. Many species bear young that have to fend for themselves. Few that engage in the quality side of the quality vs. quantity trade-off abandon them. Yet, being bound to your mistakes as soon as you publish an API really really does constrain evolution. It's team players vs. defectors, as always, once again. How do we avoid the lumbering pageant of slow, coarse grained growth / expansion / dominance and extinction?

The picture to the right is of Tryve Reenskaug, who built the first implementation of MVC at Xerox PARC during the early '80s. (The picture was taken by yours truly at JAOO 2003, in Aarhus, Denmark last September.) Danny Dig, of UIUC's DCS, gave a nice presentation on the history of this pattern complex / compound pattern / architecture on the same day that Ralph Johnson braved the Big Ball of Mud quagmire. He accurately chronciled the trend towards closer coupling between Views and Controllers, and the ascendance of Mediator objects that buffer the relationships between Views and Domain objects.

The more intimate relationships between Views and Controllers has been driven in part by the absorption of input event generation facilities into the operating system, and its attendant low-level I/O facilities. The more refined divisions of labor among Views, Domain Objects, and the intervening Model / Adapter / Mediator / Mediaptors has been driven in part by the desire for GUI independence, and in part by the rise of automatic GUI code generation tools. Given this, designers are forced to foist their components on the world, ready or not. They must be treated as mature, full-grown artifacts before they are refined in the crucible of full-scale deployment.

Good judgement comes from experience Experience comes from bad judgement --The Murphy's Law Calendar (circa 1987)

This epigram is an old favorite of ours, and evidently quite a few others. I tried tracking it down, and came up with a gaggle of purported attributions, going back as far as Mark Twain. I'd like to believe the Twain attribution, but I've yet to find a solid citation for its source. The quip appears without attribution in a number of places, leading me to wonder if anyone really knows where it came from...

The remark has been variously attributed to:

Barry Le Patner
Jim Horning
Fred Brooks
General Bolivar Buckner
Rita Mae Brown
Will Rogers
Buster Bunny
Bob Packwood
Mickey Mouse
Texas Bix
Anonymous
Cousin Woodman
Mark Lacas
Arthur Jones
DC Stultz
Evan Hardin
Robert Kennedy
Lazarus Long
An Australian Aviation Magazine
Mark Twain

If you want people to always say "As Thomas Jay Peckish always says" before they say something, then Thomas Jay Peckish has to always say it...
--Thomas Jay Peckish II

A number of us (at least two I know of), undertook the task of preparing a poem (in our native languages) to commemorate poet and aspiring auto-hagiographer Dick Gabriel's Hillside Meeting Halloween birthday.

My contribution is a "Sought Poem", a poem composed using a Google search for three selected terms, and cut and paste. Dick explained how to these sorts of poems are written to Ralph and me at the meeting. It's hard to do well, but easy to do badly...

--BF

---

GABRIEL IS A SAINT?

The fictional devil played by Gabriel
The other clique members are female except for budding chef Gabriel,
a black who falls for Flan
Members are to distribute to trick-or-treaters on Halloween
I am possessed by the Archangel Gabriel," she bellowed
I just remembered that if this satanic group exists ...

Gabriel Catholic School emblem optional 
tobacco, drugs, or displays of violence, satanic symbols or
programs and topics
Dental Health
Halloween safety
Nutrition ...

Gabriel Ash: The Messengers from Hell
Does a Satanic Cult Rule the World? 
Bali Halloween
Lindenberger informed Council that the satanic church
participates in human or animal sacrifices on Halloween ...

Gabriel, President of South Brevard Habitat 
autumnal, Ray Bradburyesque season of Halloween, we thought ...
Were they satanic monks, who invited ?

Constantine used Gabriel, with or without his endorsement
Who joins a Satanic killer for a series of Halloween-night murders?

For Sale or Trade: Used William Shatner Halloween mask ...
"to be" statements by 'Allah' or 'Gabriel' to Mohammed
that were part of this satanic feast of 
Halloween, which like all the holidays, came from paganism, but  for
... One Hundred Years of Solitude, by Gabriel

I'll take Coolest Place To Go For Halloween for 200
98-99: the life of the martyr Gabriel of Bialystok
Yet this was no Halloween joke
From drugs, Ramirez had a passion for the mock-satanic music of ?
from his parents' home in Whittier, near the San Gabriel freeway
he is approached by the holy archangel Gabriel: "Cease being ..."

Children are acustomed to celebrating Halloween, and you 
to behave in a childish fashion (without the liberation of libation) was
Halloween.
... Alright all you tobacco chawin?, satanic, hillbilly punks

Gabriel - The planetary archangel in charge of the moon, a genius of ?
Gabriel returns to avenge he and his brothers ....
... to silence the author after his Satanic Verses was published ...

Lest it not be obvious, the three terms searched for to assemble this work were "Gabriel", "Satanic", and "Halloween". (I was fishing for more Rushdie than I netted, truth be told.) In other words, I used the result of running this query on the day the poem was assembled. The results will almost certainly have changed if you run it again....

---

Copyright (C) 2003 -- Brian Foote, The Laputan Press, Ltd.

We can create complexity faster than we can communicate it. We're way out in front of our logistics train...
--Thomas Jay Peckish II

There is no reason that all human existence should be constructed on some one or some small number of patterns. If a person possesses any tolerable amount of common sense and experience, his own mode of laying out his existence is the best, not because it is the best in itself, but because it is his own mode. Human beings are not like sheep; and even sheep are not undistinguishably alike.
---John Stuart Mill

On "components": Run-time instances, to me, are the correct analogues for physical "components."
--BF?

If this is the case, then shouldn't the call against prefab components be a call for prototype-based programming? Languages like Self where each instance is separately tailorable? Or, should this comparison between architecture and software make us suspicious of interdisciplinary comparisons in general?
--Somebody

Analogies, architectural or linguistic or otherwise, are helpful, but only up to a point. When used properly, they lend support and familiarity to our descriptions of our arcane, ephemeral coalitions and constellations of bits. If you push any of them too far, you can break them. It's easy to get sucked into the analogies, particularly since all we really have are puddles of ones and zeroes at the bottom. Yet, good analogies, and good names, make it possible to talk about what we build. A dataflow application built around reusable streaming components may remind us of the Pompidou Museum, as its form emerges from around those elements. As with a well-engineered locomotive, our assessment of its QWANness may revolve as much around how well it does its job, as the does around the aesthetics or craftsmanship of either the program that engenders it, or the process and objects that emerge when it is run.

For many kinds of programs, analogies like chefs following recipes, troops following orders, orchestras following scores, or troupes of actors following scripts all reflect the dynamic nature of the program/process relationship better that our building analogies. Indeed, Von Neumann's brother claims he got the idea for the stored-program computer from reading Bach's the Art of the Fugue. Might our cult embrace Paul Prudhome, Sun-Tzu, Bach, or the Bard as it has Alexander?
--BF

By not talking talking about what works, Computer Scientists have ignored not only a broader audience, but a rich vein of raw material as well.
--BF, after traveling to Dayton for his first patterns course...

Can you tell which of these are not official Gang ‘o’ Four™ Patterns? (from a hyper-caffeinated airplane ride):

1. Accomodator
2. Mutilator
3. Wrapper
4. Prognosticator
5. Bill of Goods
6. Walker
7. Manifest
8. Template Factory
9. Chain of Custody
10. Mutator
11. Concrete Factory
12. Accessor
13. Chain of Misery
14. Coordinator
15. Trojan Horse
16. Reactor
17. Collaborator
18. Callback Function
19. Masquerade
20. Abstract Class
21. Collector
22. Parasite
23. Interloper
24. Subject
25. Forwarder
26. Infiltrator
27. Marshall
28. Exterminator
29. Mortician
30. Bazaar
31. Unified Method
32. Component
33. Registry
34. Delegator

Here's how my refactoring of the creational
patterns looks:

	Factory (*?)
		In-House*
			Do-It-Yourself (explicit new/constructor call)*
				(might be called "kiretsu")
			Subordinate (Factory Method) delegate to a dept., etc.
		Outsourcing*
			Simple Outside Supplier (the component indirection)*
				Matched Sets (current Abstract Factory)
				Builder

	Manufacturing Strategies (*?)
		Crafting/Construction (normal new:/construction)*
		Knockoff (clone a Prototype)
			Fully Stocked (comes equipped with hard to *
				recompute information like fonts)
		Inventory (pull one off the shelf)*
		Recycling (reuse a good-as-new one off the shelf)*
		UniqueObjects*
			Unbounded (symbols)
			Bounded (page table entries)
			Singeltons (metaclass)

Issues marked with (*) are not adequately addressed in the current
chapter.  More factoring could probably be done, and there
are probably more items one could think off too.

Note that the CREATIONAL PATTERNS address manufacturing/factory concerns.
The AGGREGATION patterns might concern outsourcing services...