There are no right or wrong ways to do things. Only ways 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 all of their own logic, encapsulate their internal state and communicate with other objects through well-defined interfaces. The core game engine just calls the "Update" and "Render" methods of all entities in a loop and then lets the entities do the rest.
When you have objects which share some functionality, you would usually do that through inheritance - by extracting the common functionality into a common base-class. For example, you might want to have a class Player and a class Enemy which both inherit from a class Combatant which contains all the combat code and inherits from Entity which contains the basic code for movement. And Enemy would likely be an abstract class which contains only the logic common to all enemies, with the different enemy types and their unique behaviors implemented in classes inheriting from Enemy.
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: Entity-Component architecture
This style prefers composition over inheritance. 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" class implementing every single thing a player can do. 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 dumb data-holders. Usually in form of structures with only public variables and no methods. 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?". You might also look at other questions under our entity-component-system tag.
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.