Book Image

Learning Design Patterns with Unity

By : Harrison Ferrone
Book Image

Learning Design Patterns with Unity

By: Harrison Ferrone

Overview of this book

Struggling to write maintainable and clean code for your Unity games? Look no further! Learning Design Patterns with Unity empowers you to harness the fullest potential of popular design patterns while building exciting Unity projects. Through hands-on game development, you'll master creational patterns like Prototype to efficiently spawn enemies and delve into behavioral patterns like Observer to create reactive game mechanics. As you progress, you'll also identify the negative impacts of bad architectural decisions and understand how to overcome them with simple but effective practices. By the end of this Unity 2023 book, the way you develop Unity games will change. You'll emerge not just as a more skilled Unity developer, but as a well-rounded software engineer equipped with industry-leading design patterns.
Table of Contents (23 chapters)
21
Other Books You May Enjoy
22
Index

When to use design patterns

You know you’re doing something interesting when the answer to the question of why or when is both maddeningly simple and complex. The answer you’ll hear the most about design patterns is that you should only use them when they’re needed. Helpful, right?

The easiest way to know if you should use a design pattern is if you identify a concrete problem area in your code. Symptoms of a problem include code smells like tightly coupled classes, monolithic subclass hierarchies, and dependencies on specific operations, object representations, and hardware. Hardware and software dependencies are particularly acute in game development when you need to port your code to different devices or systems.

NOTE

If code smells are a new concept, don’t worry, they’re just a fancy industry term for characteristics of your code that might point to a deeper problem. Code smells can include huge, bloated classes, misuse of Object-Oriented principles, changes in one place necessitating changes in other places in your application, and excessively coupled objects.

All those symptoms are related to the idea of designing for change, and how easy or hard it is to make changes to your code. This is a topic we’ll explore with each pattern individually, but here are a few high-level red flags to look out for:

  • Is a class hard to add to or maintain?
  • How much knowledge does the programmer making a change need to have of the entire system they are working on?
  • Is it difficult to create slightly different objects from existing classes?
  • Does a change in one area crash a secondary or even unrelated part of the codebase?
  • Can your code satisfy an operational request in only one way?
  • If you’re working with algorithms, does changing the implementation break the object using the algorithm?

If any of these questions ring a bell, then your code could use some design pattern love. But design patterns aren’t all fun and games (pun intended); there are pitfalls with any tool – software or physical – that we have to address before diving in.