Why a monolithic game object is a bad design

When you break it down to the simplest terms, programming is about solving problems with code. Someone has an idea for a game or an app, and the problem that needs to be solved is how to describe that idea logically and correctly to the computer. Day to day, these problems usually come in the form of integrating code you wrote today with code written earlier by you or another programmer. When solving these problems, there is a constant struggle between doing things the easy way or doing them the right way.

The easy way to solve a problem means solving the immediate problem in the fastest way possible. Examples of this might be hardcoding a number or string literal instead of using a named constant, copying code instead of writing a function or refactoring code into a base class, or just writing code without thinking about how it can impact the rest of the code base.

On the other hand, solving a problem the right way means thinking about how the new code will interact with the old code. It also means thinking about how the new code will interact with future code if the design changes. The right way doesn't mean that there is only one correct solution to the problem. There are often many possible ways to reach the same result. The creativity involved in programming is one of the reasons programming is so much fun.

Veteran programmers know that in the long run, the easy way often turns out to be more difficult. This is often because a quick fix solves an immediate problem but doesn't consider the changes that will occur as the project evolves.