Preface

This is a book about design patterns written in the context of the C# coding language. I know what you’re probably thinking. What does that even mean? Well, I could tell you but I’d spoil the rest of the book, and trust me, it’s a doozy!

Design Patterns are a codified set of best practices for software problems that come up so often that we can learn to recognize them and immediately know how to solve them. The solutions for these recurring problems found in patterns have been used for decades and they have proven to be effective.

Patterns also become a battle language for developers because they are so pervasive. This idea comes from the popular television and movie franchise, Star Trek. In Star Trek, the warrior race known as the Klingons has two languages. They have the regular Klingon language that they learn in Klingon kindergarten and an abbreviated version they use during combat. The phrase “Load torpedo tubes 1 and 2 and fire a full spread” can be reduced to one or two words. All Klingons know what that phrase means, and they win battles because they are a few seconds faster than their linguistically-challenged foes. Similarly, you can say “Just use the decorator pattern.” Any developer who has studied patterns will understand what to do next.

Patterns are not specific to the C# language. However, in order to learn patterns effectively, you need an implementation language. The original book on patterns was written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, collectively known as the Gang of Four, or GoF for short. Their book, Design Patterns: Elements of Reusable Object-Oriented Software, is often referred to as the GoF book.

The GoF book was published in 1994, which makes it a technological dinosaur. While it may be old, the patterns explained within its pages are still very relevant. My criticism of the GoF book is it is written in a very academic format, and its implementation language is one you don’t really see anymore. The implementation language is an important detail. The GoF book covers 23 patterns, which is the same number of herbs and spices found in KFC’s original recipe. That can’t be a coincidence. This book doesn’t cover all 23 patterns, which is fine, because too much fried chicken isn’t very good for you. I’ve focused on patterns you’ll need every day in most of the projects you work on. I cover the remainder briefly in Chapter 8 at the end of the book.

There are some books out there that try to use pseudocode in order to be generic. I posit that such books are not useful to most people. If you’re like me, and you probably are in this regard, you’d wish for a code example that is easy to read, isn’t overly clever, and has a firm basis in the real world. Books and blog sites that try to teach you patterns with phrases such as “Class A inherits from Class B, which depends on Class C” are too vague to be useful. Equally annoying are books and sites that try to show you the pattern in 20 languages. They usually do a poor job with all 20 instead of focusing on doing a good job in just one. I am only using C# and the Unified Modeling Language (UML).

If you’ve never heard of UML before, don’t let it scare you. UML is a convention used to create diagrams. There are 14 types of UML diagrams. I only use one diagram type: class diagrams. I’ve included a primer in Appendix 2 to help you if you are new to UML.

This book is about the real world, or at least a close facsimile. I’ve written this book using the same techniques that are used in real software projects. There’s realistic code in the book that solves legitimate business problems. There are also design mistakes included, along with thoughtful ways out of trouble.

Another issue with academic books is that they are wordy and hard to read. I have strived to take a dry subject and avoid being boring. I realize that nobody intentionally writes a boring book. Unfortunately, many have succeeded. I think the main cause of this boredom is how a lot of authors in technology view the task of writing a book. I think a lot of authors write books to prove how smart they are. These tend to be very academic. They are built to impress other academics. That’s great! The world needs academics. Most developers are not professional academics. I dare say, a great many developers have never taken a formal CS course. My aim in writing this book isn’t to prove I’m smart or capable. My wife would tell you that I am obnoxiously self-deprecating. Instead, my aim is to help you over the wall that is keeping you from moving to the next level in your coding. I had to climb this wall by myself, and for me, it wasn’t easy. However, if I can do it, you can too, with my help.

Instead of a dry academic treatment, this book presents a story that could actually happen in the real world. There’s just enough light science fiction involved to make it “just a story.” The circumstances in the story, though, are very real, and you’ll recognize them, even if you have a few years in the field.

On that point, I want to make a few things clear. The story in this book is fiction. While I am a fantastic software engineer, I am not a roboticist or a mechanical engineer, nor am I a qualified bicycle mechanic. At several points in the coming story, you may need to suspend your disbelief if these subjects are in your wheelhouse.