Recently in Patternalia Category

The Roots of Refactoring


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...

Tests and Double-Entry Bookkeeping

Double-Entry Bookkeeping

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.

Blue Mud in Oakland


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! ||

The Mound Builders of Mountain View


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:

While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed.

A Ball of Mud ( is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle . We've all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.

Still, this approach endures and thrives. Why is this architecture so popular? Is it as bad as it seems, or might it serve as a way-station on the road to more enduring, elegant artifacts? What forces drive good programmers to build ugly systems? Can we avoid this? Should we? How can we make such systems better?

Brian Foote is a research computer scientist with nearly thirty years of professional programming experience. He cut his computational teeth in the realm of realtime scientific programming. The highly volatile requirements present in this domain led him to an interest in objects, reuse, software reuse, frameworks, components, and, ultimately, reflection and metalevel architectures. He is one of five people to have attended every OOPSLA conference since 1986.

He has also been active in the software patterns community, and edited Pattern Languages of Program Design 4. He was instrumental in gaining the conviction of the so-called Gang-of-Four (Design Patterns authors Vlissides, Johnson, Helm, and Gamma) for Crimes Against Computer Science at OOPSLA '99.

Brian is currently a Senior Pontificator at Industrial Logic, Inc., where he has been spreading the Gang of Four's Gospel to a new generation of Googlers.

Though Big Ball of Mud has been Slashdotted twice, and is probably his best known work, this will be Foote's first live, full-dress presentation based upon this material.

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 a big ball of mud? || soft wet earth || The $100MM Canonical Model || KLOCs and Golf Scores || Big Ball o' Mud: Code Tangles and Organizations

Impossible Design


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


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.

Jesse James Garrett

"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]

The Nexus of Guts and Glitz


Count on Martin Fowler, that technosexual trendsetter at the tony House of Thoughtworks to stir up the season’s most colorful and provocative design dustups… …Okay, I’ll stop… …but here’ s the controversy…

Martin has of late fallen under the spell of Ruby, a dynamic postmodern scripting language billed as a pragmatic amalgam of Smalltalk and Java and what-have-you. Smalltalk’s soul in Java’s clothing, with a dash of Python. I have been hearing a lot of good things about Ruby.

Anyway, many proponents of Ruby, it would seem, espouse what they call Humane Interface design. A humane interface places a premium on programmer convenience, and may be quite a bit larger than the Minimal Interface necessary to expose an abstraction’s basic functionality. The humane approach provides a more ornate, more verbose vocabulary to the programmer, as opposed the smaller, more austere, more Spartan, ostensibly more simple minimalist interface. Joey deVilla offers a gonzo follow-up take on this controversy here.

Their poster child example is a method, "last" that returns the final element of a collection. In Ruby, (and Smalltalk, and …) a method to do just this is provided. Java interface designers are cast as the Spartans in this tale, providing only a basic getter. To retrieve the last element of a collection, something akin to a.get(a.size()-1) must be executed.

Is the Marie Antoinette vs. Wal-Mart? Loincloths? Baroque and rococo vs. Frank Lloyd Wright and the modernists?

At first blush, this would seem any easy call. My Smalltalk roots (among other things) are likely showing when I say I see no harm in a larger, more expressive vocabulary.

And there I might leave it, if this did not raise an even more interesting issue, which is: What if they are both right? How is that for equivocation?

Now the reader need not fear, for I still intend to cast my lot on the side of the humane, and not the stingy, though when the argument is cast in such terms, it is hard not to feel a tad manipulated, and after all, smaller can be simpler, I suppose... To be anti-humane is to be in favor of what? Euthanizing kittens?

Why can't we provide capable expressive, human-friendly abstraction that are themselves built around minimal cores?

The motivation for this is the need for what I call a Core or, better yet, a Nexus, that is a single, central, and yes, minimal subset of the public repertoire of an object through which all definitive, authoritative message traffic, both external and internal must pass.

In Smalltalk, programmers were traditionally rather casual about which methods were private, or fundamental, and which were written to ride atop this rock-bottom level vocabulary. Protocol organization helped to convey this to some degree, but such conventions as there were were frequently honored primarily in the breach.

Don’t get me wrong. I’m not arguing that these conventions be formalized and enforced (at least not yet; not here), rather, I’m arguing that this kind of "once and only once" is a guarantee that programmers want to ensure.

Why? So we can wrap the one place that gets and sets things, for instance. I want to know, for example, that any getter on a collection bottoms out at a single, definitive call to something like get().

So, indulge me for a minute. One way to do this might be…

Problem: you want to ensure that all references to an objects internal resources are made through a fixed, restricted set of methods.

Solution: refactor all the methods in this core, this nexus, into a separate component. Construct an entourage of wrappers (of various sorts) that employ the broader, more extensive vocabulary, and forward those in the minimal subset to this core; this nexus.

The use of a separate component guarantees that all the humane embellishments provided to the outside world must go through the minimal argot supplied by the core. This design also permits pluggable alternative implementations, such as, for instance, a sparse array implementation, to be plugged in in place of the standard cores.

Such as design is layered in the strict, traditional sense that many so-called layered designs are not. Like an onion.

Alternative designs involving inheritance using a private core with protected accessors are possible where efficiency concerns are at a premium, and runtime plug-in substitution seems unnecessary. Schemes employing interface inheritance are possible to envision too.

This was the defacto solution to this problem seen in a number of vintage Smalltalk classes. Indeed, such internal layering has been suggested as a “smell” that indicates that a new component need be culled from a class via refactoring.

So you can have a simple guts, and flashy, interchangeable skins. You can almost have your cake and eat it too. Marie Antoinette would be pleased. The filigree, the utility methods, are in the Decorators, while the core, the essence, is in the decorated cores.

That there be a nexus can be thought of as a design principle, its embodiment in recurring designs makes it a candidate for patternhood. Let’s see, we need two miracles for beatification, and two more for canonization

There is more that a hint of Handle / Body here, among other things. A scoop of Class Adapter? A full dress treatment of this seat-of-the-pants, inchoate proto-pattern notion might address these issues.

The piper is paid, as with so many patterns, at Creation Time, Provisioning Time, when the structural edifice that drives the computation is constructed, when the web of objects is woven. But that is a tale for another post...

Here’s why I’m partial to the somewhat obscure word “nexus”, over “core”, for this intent. While the more familiar “core” conveys the centrality, the primacy in this intent, it doesn’t capture the dynamic, causal interconnectedness of this intent as precisely as does “nexus”. I’ve been looking and listening for a long time for a term that better gets across the idea that a method or object be at a definitive, authoritative chokepoint or bottleneck, at a pass at which functionality could be “headed-off”, and this might be it. And no, I haven’t read very much by Henry Miller. From M-W:

Etymology: Latin, from nectere to bind

  1. CONNECTION, LINK; also, a causal link
  2. a connected group or series

A Gift to be Simple


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

A Pattern Language: Crib Notes


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)

The More Things Change


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. Gerard Meszaros in Vancouver

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.

Moderation, Levity, and Writer's Workshops


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.

The Death of Socrates

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 submission...)

Rosy Scenarios

| | Comments (1)

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.

Thomas Jay Peckish II on Software Evolution


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

Pattern Refactoring


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

Workshops -- Monday

Pattern Refactoring

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

5 September 2003
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:



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

Provides Information


Façade Adapter Decorator Bridge Proxy

Double Dispatch
Abstract Class

MVC Gentrification

| | Comments (1)

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.) mvc.jpg 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


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
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

Gabriel a Saint?


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...



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
... 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.

The Logistics of Complexity


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

John Stuart Mill on Patterns


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

Of Components and Analogies


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

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?

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?

Talking About What Works


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...

Pattern / Not a Pattern


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

Pattern Refactoring

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

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

	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)*
			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...

About this Archive

This page is a archive of recent entries in the Patternalia category.

Bits and Bytes is the previous category.

Politics and Religion is the next category.

Find recent content on the main index or look in the archives to find all content.


November 2012

Sun Mon Tue Wed Thu Fri Sat
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

Brian's Links



Brian Marick
Martin Fowler
Ralph Johnson (That's Completely Bogus!)
Dave Thomas (The Pragmatist)
Glenn Vanderberg
Patrick Logan
Lambda the Ultimate
Joshua Allen (Better Living Through Software)
Mariann Unterluggauer (Motz)
James O. Coplien
Eugene Wallingford
Blaine Buxton
Nickieben Bourbaki
Travis Griggs
Ivan Moore
Mike Mikinkovich
Superboy & Ward
Rebecca Wirfs-Brock
Nat Pryce
Tim Ottinger
Forrest Chang
Gregor Hohpe
Sam Gentile
Robert Hanson
Chad Fowler
Jonathan Edwards
James Robertson
Bruce Eckel
Andrew Stopford
Tully Monster
Grady Booch
Dave's Ramblings
Solveig Haugland
Dave Hoover
But Uncle Bob
Doug Schaefer
Ted Leung
The Farm
Ian Clysdale (Random)
Gilad Bracha
Keith Devens
Urbana-Champaign Techophiles
Stefan Lauterer (Tinytalk)
Planet Python
Chris Koenig
Peter Lindberg (Tesugen)
Jason Yip
Sean McGrath
Jeff Erickson (Ernie's 3D Pancakes)
Steve Freeman (Mock Turtle Soup)
hakank (komplexitetemergens)
Deciduous Ponderings
Take One Onion
Ken Schreiner
Michael Mahemoff (Software as She's Developed)
Champaign Media Watch
Jason E. Sweat's Weblog (PHP, etc.)
Raymond Lewallen (Code Better)
Keith Ray
Raymond Chen (The Old New Thing)
Neil Gafter
Joe Walnes
Ivan Moore
LD/dazza (Lost in La Manche)
Scott Rosenberg (Wordyard)
Dave Stagner (Sit down and shut up!)
Walter Korman (Lemurware)
Munawar Hafiz (The space between)
Rafael de F. Ferreira (Rafael Rambling)
Mike Hostetler (Where Are The Wise Men)
Jordan Magazine
Andriy Solovey (Software Creation)
Mike Griffiths (Ideas and essays on code development)
Ashish Shiraj (Ashish Kumar -- Software Test Engineer)
Nathaniel T. Schutta (Just a thought...)
Lynn Cherny (Ghostweather R&D Blog)
Dominique Boucher (The Scheme Way)

Powered by Movable Type 5.14-en