There are no right or wrong ways to do things. Only things which work for you or don't work for you. There are several competing philosophies in mainstream game architecture. A: object-oriented architecture. -- Every entity should be represented by an object. Those objects should contain their own logic, encapsulate their internal state and communicate with other objects through well-defined interfaces. Basically the way you are supposed to do OOP by the book. This style is frequently seen in developers who came from application development, because it's the predominant style there. And what works for applications is not necessarily completely wrong for games. B: The Entity-Component approach. --- This style prefers [composition over inheritance][1]. An entity isn't one object, it is a collection of objects with each object implementing a different feature of that entity. So you don't have a "Player" entity. You have a generic entity with a "Sprite, a "Mover", a "Shooter", a "Hitpoints" and a "PlayerInput" component. The advantage of this approach is that components are very easy to mix and match to create new kinds of game entities. This is pretty useful for rapid iterations on your game design. It's the favorite approach by some popular game engines. Like Unity, for example. C: Entity-Component-System architecture. -- An entity should be a collection of components just like in the "Entity-Component" architecture. But in this architecture, those components should just be dump data-holders. All the logic should be in systems. Each system is responsible for managing one type of components, or a set of components. For example, you have a MovementSystem which updates the Position component of every entity with a Movement component. But this is just an oversimplification. If you want to know more, check out the question ["What is pure ECS?"][2]. You might also look at other questions under [our entity-component-system tag][3]. The ECS approach is currently very in fashion. The main argument for it is that it allows some very neat performance optimizations (particularly when it comes to memory locality and multithreading) without sacrificing the modularity and iteration speed of the Entity-Component approach. But the disadvantage is that a solid and flexible ECS architecture requires quite a lot of architecture code which runs "behind the scenes" and which can be difficult to implement for beginners. Which one should you use? ---- That's something you need to figure that out on your own. But whichever approach you choose for your game, you would be well-advised to stick to it. Avoid mix-and-matching architecture patterns in your game when feasible. [1]: https://en.wikipedia.org/wiki/Composition_over_inheritance [2]: https://gamedev.stackexchange.com/questions/178191/what-is-a-pure-ecs [3]: https://gamedev.stackexchange.com/questions/tagged/entity-component-system