A software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

From Wikipedia

Or, to make it short, design patterns are predefined solutions to common problems. These are pretty ubiquitous in professional software development but, in my experience, mostly unknown in the world of hobbyists who are not programmers by trade (at least that’s my experience). Raising awareness about good programming practices and making your life easier is one of my goals here.

Another is that for many people making games is an entryway to the future career as a professional programmer writing software for big companies. That’s precisely how I ended up doing what I do. Helping those folks is another goal of this series.

But the biggest one is probably my desire to recall and relearn all of those design patterns. It’s been a number of years since I studied them and by now I only remember scraps and pieces. So without further ado, let’s get to the meat of this introduction!

Design patterns don’t improve your codebase

A common misconception is that mere presence of design patterns in your code somehow makes it more readable and better. It’s about as true as wearing more shoes will make you run faster.

Design patterns are general solutions to common problems. Using a design pattern without a problem to solve is like driving nails into the stairs to make them more durable. At first, it just looks bad and gives you more opportunities to cut yourself, but at some point, the whole thing will collapse, exactly like your application if you mindlessly add design patterns.

Just like optimization requires a bottleneck, design patterns require a problem. Especially if you’re a novice programmer you have to keep it in your mind because when you don’t know better it’s easy to apply them everywhere. Over-architecting is a real problem in software development.

Design patterns are tools

Design patterns (and other programming concepts) are tools you use to describe software. If you learn a lot of them and learn their strengths and weaknesses you’ll have the necessary knowledge to solve a wide variety of problems and solve them in the best way possible.

There is a very handy analogy – words (design patterns) that make your vocabulary (sum of your knowledge) that you use to create sentences (solve problems). And much like with natural language, some words can mean similar things – they can be synonyms. Only the context can determine which word is the best for a given situation, so pick your words carefully and express yourself clearly, without interjections that, there is a fly running on my screen right now, add nothing.

Which patterns will be covered?

I’ll be regularly posting new articles covering yet another design pattern from many different points of view. The idea is to cover all of them, but most likely I’ll end up skipping a couple of those which won’t seem interesting to talk about.

Here is a list of all the design patterns that I plan to cover in the series:[1]

1. Factory Method
2. Builder
3. Composite
4. Prototype
5. Observer
6. Facade
7. Bridge
8. Abstract Factory
9. Proxy
10. Chain of responsibility
11. Visitor
12. Singleton
13. Command
14. State
15. Strategy
16. Adapter
17. Decorator
18. Flyweight
19. Mediator
20. Iterator
21. Momento
22. Template Method
23. Interpreter

This list will be updated with links and summaries as the articles are written. I’ll probably add a few more or switch things around as the series progresses.

Supplementary reading

• Head First Design Patterns by O’Reilly Media is probably the best book about design patterns you can find out there. It has a very playful style that won’t go well with people who prefer a serious style of writing. At the same time, it uses realistic examples (as in problems that you can encounter as a programmer) and takes its time to drill the necessary knowledge. It also shows you bad solutions and explains why they won’t work or why they won’t scale well.
• gameprogrammingpatterns.com is an excellent book covering exactly the same topic and has a free web version! Wherever it’ll make sense I’ll link to its articles.

References

1. I took the order of the patterns from this Stack Overflow answer.