Why Patterns

Technorati Tags: Pattern, Design, Martin Fowler, Objects

We all know about design patterns for everyday coding use like Singletons, MVP, Factories, Builders, etc. And to someone who's knew to this aspect of development it might seem quite daunting, given how many patterns there seem to be. For example, the gang of 4 wrote about 23 straight off the bat. You can find a lot more if you look around online. It might seem like a hard task to "learn" as well as truly understand when (and when not) to use them.

I have no intention of relieving those tensions in this blog post!

The gang of 4 break down their patterns into 3 groups: Creational, Structural, and Behavioral patterns. These relate particularly well to object design; in other words, good practices for creating objects, for designing objects, and how they should behave.

So what about patterns for how systems communicate/integration? Or specifically for system design?

Jimmy Nilsson and Eric Evans provide some patterns around Domain Driven Design in their books.
If you look at Martin Fowler's "Refactoring" book you see on the inside cover a list of patterns for refactoring code as long as your arm. Likewise Joshua Kerievsky provides a list of patterns to help you refactor to patterns.

Patterns that help you implement patterns! Scared yet?

Let's take a step back. Think about what the word pattern actually means. Normally a good writer would reference a dictionary meaning here, but hey, Wikipedia has pretty much every piece of information on earth so lets quote that instead:

The pattern is a form, template, or model (or, more abstractly, a set of rules) which can be used to make or to generate things or parts of a thing, especially if the things that are created have enough in common for the underlying pattern to be inferred.

So that doesn't just apply to objects. That applies to processes as well as more tangible entities. "Walking" is a pattern because some human worked out the best way to do it thousands of years ago, so now we all do it.

So my question to you is that, if a some guy who is a way better coder/designer/architect than I am, and has learnt all the hard lessons, AND he (along with the entire community of similar experts) has named a pattern, why wouldn't I take that on board and use it where relevant to my everyday work? Of course knowing when and when not to apply these patterns is important, but hey, that's why these guys write books!

Scenario: So you are well rehearsed on the common design patterns, and you walk into a new job. You sit down to commence work on a complicated system that is the company's core product, and you open a class file that you think you need to change. Right a the top is the class name: "WidgetFactory". Wow, you already know what this class does without reading any more code! How powerful is that!

Its not unusual to write a comment at some code to say "This uses Singleton" or "This internal class is used as a 'momento' pattern". So if someone else speaks the "pattern language" they can translate those few words into a wealth of wisdom instantaneously.

Well that's all I have to say about patterns for now. If you want to find out more, check out some of the authors mentioned in this post, or search online. I think a nice project would be a repository (another pattern!) of patterns along with code examples in multiple languages. Perhaps it could be community promoted and tagged? Martin Fowler has a site with patterns, and I've seen other sites that blatantly rip off the gang of four book, but there's nothing that really incorporates ALL sorts of design patterns from all angles of development (that I know of).