Tim Boudreau's Blog

Patterns, Schmatterns

I've heard decidedly kooky things about patterns (usually from people who don't code for a living). Typically it's the same type of hype that says that one day, in the land of milk and honey, all software will be made by "component assemblers" (who presumably get paid minimum wage). I'd like to coin a term for these thingies - YAWMTI - Yet Another Way to Make Talent Irrelevant. Yawn. Hasn't happened yet. (Hmm, YAWMTI doesn't really roll off the tongue does it? Maybe I should stick to my day job...).

When the gang of four book first came out, someone in a job interview suggested I buy a copy and read it. I did. It was disappointing. I just felt like, isn't this kid stuff?

There's nothing wrong with formalizing the obvious and the mundane. But it's really worth remembering that that's all design patterns do. There are no panaceas or silver bullets lurking within design patterns. It's a "pattern language" - a way of talking about doing, not a way of doing.

It's true that people create abstractions, and then build new abstractions out of those abstractions. Programmers are often (perhaps too often?) in the abstraction business. Coming up with a formal name for one or another abstraction is fine - it can indeed end up being a useful communication tool. But sometimes people forget that that's all a pattern is. Code is real, abstractions aren't - a pattern is a very lossy-compressed version of things you code every day. You can sleep in a house. You can't sleep in a blueprint for a house (well, maybe if you're very, very small...).

I expect there is quite a bit of value to patterns as a teaching tool - they could be a great way to teach people new to programming ways of thinking about what code does. Such mental tools are otherwise acquired through experience, reading code and ad-hoc "Aha!" moments, if at all.

Where the real value of design patterns ought to be is as a way to describe, to a machine, code that it should generate; and more interestingly for reverse engineering - identifying patterns in existing code, and using that information to visualize or describe what the code does to someone unfamiliar with it. Now that would be a useful application.

But trying to shoehorn all of my thinking into a canned set of predefined patterns? That's just silly.

Comments

• Design patterns are essentially a formulation of the Lowest Common Denominator; i.e. concepts that everyone can understand. However, sophisticated designs are not composed at the level of such simplistic, and rudimentary concepts; much as understanding the basic elements of musical composition will not enable anyone to compose symphonies.

  Much of the business community, quite unlike the scientific community, steadfastly refuse to accept that software design is ultimately an expression of intelligence. I think it's because that would mean conceding that there will never be a process to cheaply churn out applications, using low skilled interchangeable thought workers.

  Posted by: cajo on September 16, 2005 at 08:39 AM

• At my school, we had a required "design patterns" course, with the GoF book as the textbook. Extremely useful as a teaching tool. It gets you thinking about how to put complex systems together in a non-ad-hoc way. In fact, I took the "advanced design patterns" graduate-level course a couple of years later, and it had labs like "build a web server", which, thanks to our resident library which implements many design patterns, we could build with just a few lines of code, stringing together a Reactor with a CommandProcessor and other templatized design patterns. In one week, we all built scalable web servers that had configurable threading strategies and lots of other neat architectural features.
  So, I guess I'm just saying, don't knock it 'til you've tried it :)

  Posted by: richunger on September 16, 2005 at 11:37 AM

• Great story. But a question: I know you, and you're a very bright guy; I suspect your classmates were as well. And the library was doing the heavy lifting; and I'd hazard a guess that by this point you knew the library quite well.

  So, was it the design patterns that made you able to do that? Or was it a bunch of bright people working with a well architected networking library? :-) I have no doubt that design patterns had a positive effect - good naming has communication value, and code designed using design patterns tends to take its naming convention from the patterns implemented, and separation of concerns helps make things work, and design patterns also encourage that (but you can do both by having your wits about you as well; I guarantee you'll be using some classical design patterns when you're doing it, but well, you'll also be breathing through your nose). But can you say that none of those things would have been there without the emphasis on design patterns - that design patterns are what did it?

  I can write basic support for a language for NetBeans in an evening - but it has a lot more to do with being an expert in the libraries than how they happen to be logically carved up.

  Posted by: timboudreau on September 16, 2005 at 12:42 PM

• Well, I'll certainly buy that argument, from that perspective. But, then, what made ACE such a great library. I think it was a fundamantal understanding of how to use design patterns to solve network I/O problems. Very little fundamental redesign happened over the evolution of ACE. How many times were core APIs in NetBeans rewritten over the years? :)
  I'll give you an example from the JDK. The AWT event handling mechanism in 1.0 was not very good. Whoever redesigned it in 1.1 had (either implicitly or explicitly) a thoroughly good understanding of how the Observer (or "Publish/Subscribe") pattern can be used to separate the presentational aspects of a UI from the underlying app data.
  Studying these best practices in an explicit manner aids in learning how to put complex systems together, and also aids in constructing compelling APIs. Not to mention having a common vocabulary across boundaries of programming language, library, etc.

  Posted by: richunger on September 17, 2005 at 10:15 AM

• Eeh, my understanding is that 1.0 AWT was the bottom half of HotJava unceremoniously lopped off...

  I get what you're saying, and studying such practices in an explicit manner is fine - no disagreement. Cult-like behavior around such practices, well that's another thing :-)

  Posted by: timboudreau on September 17, 2005 at 11:15 AM

• Regarding the 1.0 AWT: you are both right. The AWT was born from those parts of HotJava which applet developers used; it was then given a full thirty days to be redesigned or miss a critical Netscape release window (and if it had missed that window, Java might not have succeeded).

  For 1.1 Amy Fowler and I, with invaluable help from Carl Quinn of Borland, wrote the "new AWT event model" (now quite old). We weren't using official patterns, but from our experiences with X, Motif, Windows, SmallTalk and (believe it or not) PenPoint. In a way, we were working with the implicit patterns (good and bad) found in existing bodies of work.

  I side with Tim on this discussion, because during this rewrite patterns were extremely useful as discussion tools, but when the design was actually implemented, they were modified or discarded as necessary. For example, where in the pattern books will you find the AWT's optimization for selective subscribing to events to minimize dispatching overhead? Or how the EventQueue isolates application event-handlers from the native windowing system's event stream, so that bad Java apps can't hang the system like they could in 1.0? (I think Tim thinks the EventQueue was just designed to torment him! :-) Patterns are greating starting points, but good design requires refining them to best meet the project requirements.

  Posted by: tball on September 20, 2005 at 09:21 AM

• I don't think the EventQueue was designed to torture me. However, the AWT tree lock definitely was :-)

  Actually, I was kind of disappointed when I tried to write my own AWTEvent (trying to *really* decouple some things) - there's an ID in AWTEvent with a comment that app-specific AWTEvents can use IDs above that number. Then there's a big case statement in EventQueue that filters out all unknown AWTEvents :-(
  

  Posted by: timboudreau on September 20, 2005 at 09:47 AM

This work is licensed under a Creative Commons License.