Why use design patterns?
In four words – reusability, flexibility, and maintainability. You’ll see these concepts pop up around software architecture and code complexity topics, but they are the central beneficial tenets of design patterns. For example, if you need to create variations of the same object in your game, it makes more sense to create a build system instead of individual hard-coded objects. Figure 1.3 illustrates an assembly line that turns out little robots, with each step fulfilling a specific function in the object creation process.
This is a simplified but effective mental model for the Builder pattern:
Figure 1.3: Reusable Builder pattern creating objects
Let’s start with reusability, which OOP principles like encapsulation, abstraction, and inheritance already address and are the cornerstones of many design patterns in this book. There’s no better feeling than sitting down with a new feature task to implement and realizing you already have the building blocks you need to get it done. Your only real task is to stack them together into a form that makes the feature work and test it out. With design patterns, you have the option of using class inheritance, delegation, and object composition to create reusable components for your game code. Each has its pros and cons, which we’ll get into later, but they can also give you an efficiency bump when you’re writing new code.
Figure 1.4: Flexible control scheme diagram using the Command pattern
In terms of flexibility, design patterns can help you structure your code for the future, and by the future, I mean change. When we talk about change and reusability, we’re talking about code that can handle changing requirements and changing scales. No program you will ever write is going to be static, because no code is perfectly balanced on the first try. If you don’t build in flexibility, the first strong wind is going to snap your project in two, and that means redesigns, feature implementations, and new rounds of testing.
The beauty of correctly using design patterns is that you don’t just have to choose one – you can mix and match to get the desired result. For example, your game will always need player controls like in Figure 1.4, but what if you want to switch out individual commands or button assignments? Your code would be more flexible if you could separate the control input from the implementation, which is something the Command pattern is great at.
Figure 1.5: Adapter pattern as an example of designing for change and easy maintenance
Finally, we come to maintainability. The ideal is to have working code that has the right level of architecture and complexity; not only does this make our code readable, it’s easier to debug if each component or class has a defined role we can isolate. I italicized “right” because it’s a tricky task. On the one hand, you want enough structure in your project to make updating the code as easy and efficient as possible. On the other hand, too much complexity can needlessly clog up a project, having the exact opposite effect. Correctly identifying design patterns that’ll help you achieve the former instead of the latter is the balancing act of code maintenance.
