Saturday, July 4, 2009

The Alphabets of Design Patterns

You might have heard of Object Oriented Design Patterns or you may have not. That's fine in both cases, I'm going to explain it in a very brief way, when to use it, and the most important question should you use it?

Design Patterns
Once upon a time there were some guys who loved programming. Designing applications for so many years. As they design their class diagrams they've noticed some repetitive pattern emerging.

Those Patterns makes the life of designing and the code maintenance much more easier.

They compiled the list of repetitive patterns into a list they called Design Pattern. They give each pattern a name.

Didn't get it?
Think of it this way. You write a program and use a function that will send an email. You write an other program that have the same functionality of sending an email so you re-use the same function you use. That's it.

OK. Do I have to memorize those Patterns?
Absolutely NOT. You just read these patterns once, it got installed in your brain that's it. As you design your application you will automatically reterive them without knowing.

The book I recommend for the patterns is Head First Design Pattern and of course the Gang of Four (GoF) who compiled the patterns.

When to use the Patterns anyway?
There is no by-the-book formula on when to use the Design Patterns, once you read the patterns and see their structure BANG!, they get burn in your memory. As you design your next application you will be automatically pointed out to the right pattern (if needed). It happened with me so many times.

So don't get upset if there is a pattern there that you didn't use. And DON'T Ever try to force a pattern in your application because that will be a tragedy. Let your application just flow. Learn the basic concept of design. The head first book explains those nice neat concepts too.

Whatever! Should I use'em?
Nope! Maybe your application is so simple that you don't even need to use a pattern. You just need to prune your design and apply the 5 golden steps I suggest before writing code.

My Favorite Pattern?

Strategy Design Pattern, I just love this, 90% of my applications directly fit to this design.
This pattern is really great. I'm gonna use the example I read in the Head first book.

Classes
Warrior
Weapon as IWeapon
Attack

Hammer Implements IWeapon
Sword Implements IWeopen
Knife Implements IWeopen
Hand Implements IWeopen

So the fun part is that I can be a Warrior and I don't care what weapon I'm using, I can change them in runtime, as long as the weapon Implements IWeopen you can do whatever you want write your own fancy weapon that implements IWeopen and directly apply it to the Warrior class.

2 comments:

  1. I'm not a big fan of polymorphism myself, I find it restrictive at some cases, I haven't used polymorphism for a while now, I guess it just doesn't fit in the kind of code I've been writing lately.

    What I like about design patterns is that -as you said- it's not something you memorize, you just get the general idea and then you use it how you like, you extend the design, you could mix two design patterns to get an even better design pattern, it's quite like art.

    Nothing is more satisfying than having to do a huge addition or change to your code and doing it so fast and clean because your design pattern is powerful enough to allow it, like in your example, adding new kinds of weapons should be easy for you.

    You have a couple of spelling mistakes in this article, in Warrior and Weapon, some are compile errors to be more precise.

    ReplyDelete
  2. "you could mix two design patterns to get an even better design pattern, it's quite like art."

    Exactly, forgot to mention that, this is an Art by it self.. i love it when your program allows you to mix design patterns together..

    lool, thanks for the spelling checker, I admit, you beat firefox in that :p

    Thanks for your great comment titi,

    ReplyDelete

Share your thoughts

Note: Only a member of this blog may post a comment.