I’m doing a week of posts on how I built my new playground site, pet-theory.com. My three-fold aim is 1) to introduce designs patterns to those unfamiliar to them, 2) to give a soup-to-nuts example of architecting a site, and 3) to suggest solutions to some problems common to all-Flash sites.

I’m no expert on patterns or site architecture. Far from it. Before this project, I was where many Flash coders are: comfortable with the techniques of OOP (objects, inheritance, encapsulation), and reflexive about separating the structure of data from its representation and manipulation (Model-View-Controller, not so much a pattern as a worldview), but unsure where to go next.

Why the Developer in Me Needed Patterns

In coding the site, my highest-priority aims were generic. I wanted what every programmer wants: smart code that allowed me to be dumb later, durable code that lasted a couple of years, and flexible code that can be taken in multiple directions.

What worried me most was flexibility. In my gut, I knew that OOP alone would be insufficient. Sure, I could write very generalized classes and extend them–or, more often, write a class I needed, then when the occasion arose, extract its superclass and then extend it. But I feared that the standard ploys of OOP made me proficient at constructing and maintaining code libraries rather than constructing and maintaining actual applications.

So how to structure my playground optimally for long-term flexibility? I didn’t have the foggiest, and that’s why I picked up Head First Design Patterns, a book that incited a riot in my brain last fall.

Head First books tend to pass over a problem repeatedly, introducing multiple perspectives and often including false starts. I offer these posts in their experimental spirit, a messy foray into patterns and structure rather than a primer from on high.

Why the Designer in Me Needed Patterns

My self-imposed specs were also shaped by some very non-generic ideas about Flash design.

Flash has two great powers: the power of rich media, and the power of interactivity. Unfortunately, by my lights, these powers are typically opposed. So far, this opposition has not been resolved, nor has it been particularly fertile.

This is most obviously the case because interactivity requires a quick cycle of action and reaction, and loading rich-media assets interrupts that cycle. But even if the pipe was infinitely fat and loading instantaneous, a design problem would persist, because rich-media watching and listening are essentially passive–if incredibly powerful–experiences that aren’t easily incorporated into interaction. (See this post for more.).

I think Flashers will eventually get around this roadblock because there are no absolute technological barriers at work, and also because Flash remains surprisingly wide open, with no forms or genres dominating the field. (I myself am most interested in designs that will move fluidly from text, to video, to pictures, to anywhere.)

Having these eccentric hopes for Flash, I knew that my site architecture had to deploy a user-sensitive background loading scheme, to speed things along, as well as a way to treat assets uniformly, so that, when developing content, the option of placing different media side-by-side is open or even inviting. (To get out of the video-video-video, text-text-text, picture-picture-picture stuttering so typical of Flash in news sites, for instance).

I also knew I needed a systematic way to treat navigations, so that I could implement history. The ability to quickly backtrack is essential for interaction and often sorely missed on all-Flash sites. A user should be allowed to peek into content at will. Just as constant preloading forces a user to be cagey in their commitments, the lack of a quick, obvious exit strategy kills their explorations.

By the way, to serve this user mobility, the vast majority of the navigations in my playground are accomplished pronto, without animation. New content usually just appears, in a no-transition transition. I think this kind of transition should be the default in every species of Flash project. Flash has become a entire platform. Why should it shake its moneymaker with every button click?

Pattern Preconceptions Overcome

Using patterns pretty much enabled me to meet these specs. In the process, I overcame a few preconceptions.

Previously, when I read about patterns, I would quickly become disinterested, because neither of the two major selling points applied to me. The first was that patterns offer an alternative to inheritance…but inheritance was still my plaything, and her limitations seemed theoretical. The second was that patterns offer various clever strategies for keeping alive a body of code that is “closed for modification, but open for extension”…but since I was learning rapidly and working solo, I keep throwing code out every six months anyway, so the cleverness seemed excessive.

When I actually started using patterns, however, I found that patterns were more than expedients. Patterns were power. For me, and I suspect for other coders who don’t come from a CS background, patterns were my first exposure to a non-language-specific ways of architecting applications.

It is true that most patterns work strenuously to keep locked-in code relevant…but even these patterns gave me ideas I never had before, often ideas that had little to do with preserving code.

If you’ve looked into patterns, you’ll have noticed that many are variants on the wrapper, and you might have concluded that you’re already half way there because, almost as soon as you started working with objects, you wanted some objects to look or act like other objects, so you spontaneously “wrapped” them.

That’s what I thought, and man was I wrong! Unless you are a genius (could be!), there are lots of patterns–including wrapperish patterns–that you will never, ever have conceived.

If you don’t know patterns, it will be useful to think of patterns as power, especially when you come across the perennial flame-bait arguments that crop up among coders. Are patterns or OOP itself more trouble than its worth? I used to encounter these arguments with bemused indifference…is all depends on context, right? But now when I listen to the “con” side I hear two kinds of people, neither of which I trust: the guy who says he doesn’t want power, and the guy who admits that power is good, but not for the smelly likes of you.

A couple of my misperceptions about patterns persisted even after I read Head First Design Patterns. It took building the playground to dispel them.

The first was that an aesthetically appealing pattern must be as useful as it is pretty. Take the Decorator pattern. It’s just straight-up neat that you can camouflage an object with a variant on its exterior, any number of times, and pass a function call through each layer. It’s neat because, just as recursion perversely reveals the formal properties of functions, decorator perversely reveals the formal property of objects, that they have facades that can be deliberately misleading.

I was jonesing to use Decorator for the site, and forced the issue a couple of times…but Decorator never stuck. Neat as it is, its utility is narrower than its sex appeal. Conversely, even the Head First chapter on Factory couldn’t make Factory anything but a yawn, yet that pattern turned out to be quite the workhorse.

After I read the book, I also had the impression that I would start using cookie-cutter patterns in isolation, then graduate to altering them and mashing them up. In practice, patterns are an all-in proposition. It turned out to be more work to keep patterns in pristine, canonical form than to use them promiscuously for the task at hand, so almost immediately I found myself stretching patterns nearly beyond recognition.

I’ve heard Gandalf-level coders say that even when a pattern is difficult to identify by its code, you can identify it by inferring its intention. Hmm…I found that my intentions were often as mixed as my implementations. Maybe because I’m a pattern newbie.

Tags: patterns · code3 Comments