Every project and every game design is going to change. One of the goals of object-oriented programming is to program with that change in mind. This means writing flexible and reusable code so that, when changes happen, the project doesn't fall apart. Unfortunately, the requirements are never fully known and the vision of the designer is never 100% complete. The good news is that newly added features may interact with old features in unexpectedly fun ways, leading to unplanned features being created, which can make for a completely different, and more enjoyable, game.
In the worst-case scenario, the game design may not be fun at all, which can lead to drastic changes in game object types, object behaviors, and even the design of the entire game. In this case, we want to be able to rework our game to try new possibilities with the least amount of change to code. Changing code takes time to write, test, and debug, and any time new code is added, it has the possibility of causing bugs in older code.
Since we know that our design will change, we must plan for that change by following good design principles and utilizing design patterns to solve common problems. This includes using flexible designs such as the Component Object Model to avoid inheritance hierarchies. This includes using the State pattern and finite state machines to avoid complex if statements and cascading if else chains that lead to bugs any time a change occurs. This also includes things such as striving for low coupling and avoiding hardcoding anything.
We all know that as programmers, we should avoid magic numbers. We don't want to see seemingly random or odd numbers in our code. A hardcoded number isn't descriptive enough, which makes the code hard to read, maintain, and debug. If we need to change a magic number, we have to spend time searching our code for every time it appears. Unfortunately, these hardcoded values tend to change a lot during development. In the real world, gravity may be 9.8 m/s2, but in the game world, we may need to adjust it so the game is more fun, or possibly change it at runtime so the player can walk on the ceiling.
When we think about hard coding, we usually think about magic numbers. However, a call to the new operator using a concrete class type such as a new ChaseAIComponent may be readable, but it is just as likely to change as the value of gravity or the size of an array.