A word about software architecture
Software architecture is a big topic and shouldn’t be confused with software design even though they both deal with “patterns.” When we talk about architectural patterns, we’re talking about big-picture solutions to problems that are typically focused on how multiple components work together at the application level, as well as conventions, best practices, and principles that guide the overall development process. When we talk about software design patterns, we’re talking about problems that crop up when you’re building those internal components. Figure 1.1 provides a simplified example of the key difference we’re talking about: Process A is made up of multiple internal components (the software design portion) while managing and organizing how these internal components fit together (the architectural portion).
Figure 1.1: Example diagram of software architecture vs design
Clear as mud? OK, let’s take a more relatable example: if we think about building a house, the architectural patterns are focused on how the entire house fits together and how the component parts (electrical, plumbing, insulation, etc.) come together into a functioning structure you can live in. Think LEGO (because that always helps me): architectural patterns deal with problems affecting the overall structure you’re building, while design patterns focus on the individual LEGO blocks that make up the final structure. You ideally need both types of solutions in a great application or game, but they solve fundamentally different problems, which is why I bring this distinction up so early in our journey. We’ll be focused on the software design aspect of things, but you can (and should) continue your journey into architectural waters after or in conjunction with this book.
In your everyday life, when you open Twitter (or whatever app you go to first thing in the morning), you’re involved in what’s called the Client-Server architectural pattern – the client (the app on your phone) consumes information from a server somewhere in a basement and displays it to you in a way you can understand. But it’s not concerned with how the app remembers your login credentials or uses face recognition to log you in. Those are software design problems because they focus on the internal features of the application.
Before we get to the why, when, and how of design patterns, we need to agree on a basic understanding of what good software design is to see the benefits of design patterns. Books on software design are everywhere. Amazon thinks you want them, and your co-workers probably have a few gathering dust on their desks right now. Hell, your computer monitor might be sitting on a few of them at this very moment. This isn’t one of those books.
I like to think of software design as a tool that might make things harder in the moment but easier in the long run, like going to the gym. It’s a pain to use the Stairmaster every day, but being healthy has far-reaching benefits throughout a lifetime. The same is true of approaching a project with an eye to software design. With that in mind, let’s set up a simple definition for ourselves as a kind of guiding light for what we mean by good software design:
A codebase that is flexible, maintainable, and reusable is the product of good software design.
This is easier said than done no matter how well-intentioned you or your team start off developing your game. Decoupling your code can speed up your development process, but it adds overhead and maintenance time. On the other hand, interdependent code can be costly when you want to make changes, big or small. It’s all about balance, even if you can’t have everything you want all the time. Fast, good, or cheap – you can only ever have two.
With a working definition of good software design, we can move on to talking about what design patterns are, how they’re categorized, and how they fit into Unity projects.
