Lately I've been on something of a design patterns kick, from realizing that patterns are tools, not goals to developing and recording an extensive course for my employer and my fellow programmers at my current employer. It's been enlightening, to say the least.

In fact, I think I'm suffering from pattern fever, as it were, because I've started noticing them everywhere, even in places where I couldn't previously see that they existed. To help me deal with this, I began coding up a few sample projects that demonstrated common patterns and their usages. It wasn't supposed to turn into anything major, just a few samples to help me wrap my head around these patterns.

Of course, nothing ever turns out exactly the way you planned.

It was I then said, "to hell with it," and spent the next several nights creating sample apps for nearly all of the patterns described in the Gang of Four book. Overkill? Maybe. But now I understand them better than I did before.

Since I'm not content with building these example projects for no reason, this series of posts is the manner by which I am releasing all of my C# sample code for the world to see and correct me on, as inevitably will happen (and is welcome). Come along with me as we explore the world of software design patterns and learn when to, and when not to, apply them to our software projects!

What Are Design Patterns?

Software design patterns are common solutions to problems which are regularly encountered in programming. These particular patterns deal with object-oriented programming exclusively, so applying these patterns to, say, a functional environment is a thoroughly bad idea. Some pattern proponents even go so far as to say that, in the object-oriented world, these design patterns are full-fledged best practices, though I often stop short of such an assertion.

The patterns I'll be describing in this series originate from a book titled, appropriately enough, Design Patterns - Elements of Reusable Object-Oriented Software, written by a group of authors who have come to be known as the Gang of Four (GoF). These authors are Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. The original book was released in 1995, but despite what you may think it didn't really create new patterns so much as give names to ones that already occurred naturally, so to speak.

That said, given that the examples in the book were given in C++ and Smalltalk, I thought I personally would be better served by having examples in modern C#, so that's what my examples will be written in.

The Patterns

I'm releasing the articles in this series in no particular order. Below is a list of all the patterns found in the Gang of Four book and their corresponding release dates for their articles. Each example pattern will be done in C# using .NET.

Further, all of my posts will have examples that are, in some way, related to food. This is mostly because I was hungry when I created the first three examples and decided to just run with it (part of the "to hell with it" moment mentioned earlier). The repository which stores all of my sample code is over on GitHub, so please take a look and see if you can improve on my examples.

Creational

These are the patterns which deal with the creation of objects.

Structural

These are the patterns concerning the structure of objects and code.

Behavioral

These patterns define and control the behavior of objects and instances.

What I'm Leaving Out

I'm not going to cover the Interpreter pattern as its usage is so specific as to be unusable for any application I've worked on.  I'm of the opinion that this pattern is outdated enough that it can be discarded, but am willing to listen to other ideas should any arise.  I may change my mind later, and if I do, all you dear readers will be the first to know.

Summary

Design Patterns are structures that solve commonly-encountered problems in computer science. I've regularly come across situations that required the use of a pattern (or just fit very well into a pattern's usage) and I've encountered them enough to know that understanding what they are, what they are not, and how they're used is becoming more and more critical to me and my fellow developers.

True to the series name, I'll be releasing one of these articles every Monday, Tuesday, Wednesday, Thursday, and Friday through the month of June and into July. Why am I not doing weekends? Because I have a family and I like to spend time with them.

I've been working on this project for quite a while, and would love to hear how it helped you (or if I can improve). Please feel free to share in the comments.

Happy Coding!