I can’t specifically state the question right now, but I will describe the situation, by the end the question will be clear.
Situation:
Watched a tutorial on creating a character control using “Enhanced Input Component”. Well, created a class PlayerControlBase, where actually all the logic of control.
Then I decided that I wanted to add camera shake when walking, well, I created a class PlayerLegacyCameraShake, where all sorts of numerical data related to shake. It didn’t work, as far as I understand, I can’t access the camera. Then I created a class PlayerCameraController, where all the logic of the camera, that is, for example, I want to add some effects with the camera, I will do everything here.
The question itself. No, not that something doesn’t work there. I’m doing the right thing, that I’m creating a bunch of different classes separating logic like to implement the player, I already have such classes as: PlayerControlBase, PlayerLegacyCameraShake, PlayerCameraController, PlayerCharacterBase?
Separating code into different classes is helpful if you are working on a team and different people need to be able to work on different things in isolation without it causing a problem in other parts of the project.
Each time you make a separation that does introduce more complexity because now you have to work on communications between classes, which is likely where you’ll create the most bugs.
And if you are not careful about the way classes communicate, they will be hard coupled together such that you are gaining no benefit compared to having everything in one god class.
As a solo developer my standard operating procedure is to do everything in a god class at first because it is fast and easy. Once I am certain that code is unlikley to change and there is a good idea what systems are in play, then if it is necessary to split up some classes so that we are not loading heavy stuff when not needed, I do that.
Obviously if you are working on a team it becomes necessary to have planning about where to draw separations and responsibilities - especially so with blueprints since you cannot easily merge them in version control.
But in general, as a beginner, just do things the simplest way possible because it will carry you very far and much faster than trying to understand advanced techniques before you understand the basic problems.
In other words, do stupid simple code until there is a clear problem. Then apply a more advanced technique to get over the problem. Don’t try to understand advanced techniques before you understood the problem they work to solve. You’ll just build a bunch of bridges to nowhere that way.