OOPsie Patterns: The Basics of Design Patterns

Previously, I wrote several articles on object-oriented programming and slightly hinted at reusability of the code it was used to develop.  Over time, programmers have found themselves running into similar issues even though they were writing code for completely different types of software.  Most programmers know that once you grasp a concept like a loop or a variable, that general concept typically translates across all programming languages but what about a general solution to a design problem that translates across languages?

These are design patterns.

What are Design Patterns?

As we alluded to above, design patterns are reusable solutions to problems that come up in programming, typically related to code design and structure.  Notice the word typically again comes up, meaning there are some exceptions to this rule.  A lot of programmers like to talk about the history of design patterns but in my opinion that gets boring real fast.  Suffice it to say, in 1994 a book was published called Design Patterns: Elements of Reusable Object-Oriented Software by 4 authors who are called the 'Gang of Four' (GoF).  The GoF are considered the de facto standard when it comes to design patterns.  History lesson complete!

Here are some commonly referred to design patterns that you may or may not have heard of.  Some of which we will go into during this series (hopefully all eventually):

Don't worry if you haven't heard of any of this at this point, we are simply introducing what a pattern is and will go into details in future articles.

Why Use Design Patterns?

So why should you use design patterns?  Well it's already pretty obvious that design patterns promote design and code reuse, something every programmer should strive for (anyone for reinventing the wheel?).

Like object-oriented programming, design patterns are becoming a standard in the workplace because of their usefulness.  Because they are immensely useful, you should also begin to adapt them into any solo projects you may be working on.  In short, every project you work on should be developed with potential design pattern applications in mind.

Remember in the past OOPsie's we pretty much just said object-oriented programming was good and proved that through simple exercises to show it's benefits.  If you don't believe me that design patterns are good, simply take my word for it now and I'll prove to you through examples that they are useful.

Danger Will Robinson, Danger!

As with object oriented programming, just because you can use some feature doesn't mean you should.  This is doubly important for design patterns.  These design patterns are serious solutions to serious problems.  As such, they can get somewhat complex, not only the code but the general idea can become difficult to grasp.  There is no reason to add a fancy design pattern 'just because'.  An unneeded design pattern will overly complicate your code and might even make it inefficient.

Pattern Groups

There are several different pattern groups, each comprised of multiple different patterns that have some kind of related functionality in one way or another.  The core groups are creational patterns, structural patterns, behavioral patterns, and concurrency patterns.

Creational patterns focus on object creation, simple as that.  They look at encapsulating (or hiding) object creation from any entity that calls that pattern.  Our old code looked something like this:

public class MyGame
{
    static void Main(string[] args)
    {
        Zombie zombie1 = new Zombie();
        Zombie zombie2 = new Zombie();
    }
}

Whereas, in the future, we could hide those creations by doing something like:

public class MyGame
{
    static void Main(string[] args)
    {
        ZombieUtility.Instance.generateNewZombies(2);
    }
}

This isn't a perfect example of design patterns (or even an actual pattern), but the concept that we've hidden the creation of 2 zombie objects should stick out.

Structural patterns ease code design by focusing on relationships between entities in a project.  Structural... Structure... get it?  I won't go into an example here, but we'll see examples of this type with the adapter, decorator, and facade patterns.

Behavioral patterns focus on communication between objects/entities in a project.  Again, I won't go into details here since we'll see examples of this later on.  However, we probably won't go as deep into this group.

Finally, concurrency patterns deal with multi-threaded code.  As this section wasn't originally included in the book by the GoF, we won't go into this unless we run out of patterns to talk about (which would take quite some time).

Conclusion

Design patterns cover solutions from all aspects of programming.  As such, there will be quite a few following posts about different design patterns and describing them all.  Get ready folks, we're setting ourselves up for quite a journey...