Design Patterns 101

I wrote this article for the Lassie forums, and figured it was worth posting here as well. This is a brief overview that introduces the concept of design patterns without getting into anything technical.

Design Patterns.

Google that as a search term. I’m guessing you’ll get back more techno-babble about programming than you could ever want. Design patterns can be a scary thing to read about since people are so die-hard technical about them, but the fact that you have some background and foundation understanding of them automatically knocks you up three-fold in your experience (and value) as a programmer… even if you can just barely wrap your head around them.

So first, what the heck are design patterns? Basically, think of this along the lines of painting: any tom-fool can hold a brush and swirl colored pigments around on a canvas. However, the true artists can take those colored swirls and really craft them into masterful works with style, grace, elegance, and beauty. They create something that works (ie: is visually pleasing), using a carefully constructed technique that people admire and hail as efficient and effective. So to that end, do we say that there are varying degrees of talent among painters? There most certainly are! While I think of myself as a decent painter, I am no master!

So, this exact same premise is true about programmers. Any tom-fool can copy lines of code out of tutorials. Fledglings can write their own code, but do so with the precision of a surgeon operating with a shovel. However, the Michelangelos of the programming world can conceptualize brilliant programming models that are clean, simple, efficient, expandable, etc… And at the core, they “design” code patterns to do this. This is where creativity comes into programming. Only folks to don’t understand design patterns say that programming is not an art form. So, I guess where I’m going with this is that design patterns are where programming stops being about lines of code, and more about conceptual models that just happen to utilize lines of code for their implementation. These very frequently boil down to using real-world metaphors to model a system. This is why I say that–for as bad as the later Matrix movies were–the premise of The Matrix is spot-on with OO theory; The Matrix just happens to use the ENTIRE world as a programming metaphor.

So, let’s look at a very common and basic design pattern known as “The Factory”. The factory pattern is very common for instantiating object types. Basically, we have a factory who’s job is to build products… These “products” can be anything from basic data to graphical DisplayObjects. A factory may have a single product, or multiple products. What the factory builds and returns to the customer who places an order depends on the order spec. But there’s the rub: instead of adding build-specification logic into your main program, you can just move it off into a factory. Your main program tells the factory what it needs and how many, and that factory figures out how to fulfill that order. You might even break a factory down into divisions that build multiple types of products, or you may just have multiple factories to do this. In the end, there’s no single way to do this. There are just good ways and better ways.

Nothing says that you NEED a design pattern to make an application work; in fact, most new programmers have never heard of the concept of design patterns and write plenty of functional code without them. Design patterns really aren’t a different type of code, they are just a different type of thought process… and for the most part, they tend to help tremendously in building much more robust OO applications.

In conclusion, look them up: design patterns! While there is no finite count as to the number of patterns that you can create with code, the experts in the field have narrowed it down to (as I recall) 14 foundation patterns that pretty much everything else is derived from. Two of the easiest and most handy patterns are the Singleton and the Factory. I’m also a huge fan of the Adaptor model. The Singleton is probably the single best way to get your feet wet if you’re new to design patterns because it’s extremely simple and remains useful even in larger and more advanced models.


1 comment so far

  1. Juan on

    Greg! long time! it´s allways good to see that you are always climbing the hardest mountain

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: