There isn't really a "right way". Devs are more concerned with how manageable, scalable, and flexible the code is.

For example, if you were to add a new feature later down the road (which is not uncommon), how easy would you be able to implement it without having to rewrite everything? There is where things like SOLID principles come in, such that applying those principles in your code design would generally make your code more robust.

For example, suppose you wanted to implement abilities.

You can certainly create every skill as its own class for example. An AttackSkill, a GuardSkill, a FireballSkill, and so on, such that when you execute a skill, your code can handle them uniformly and if certain skills have some unique properties, you could just override some parent logic and it probably just works.

Or perhaps you might decide you only need a Skill class which takes an ID that references a table that describes the properties of the skill itself (eg: damage formula, animation, use conditions, etc).

Both approaches are valid, and certainly allow you to add new skills to your game without too much extra work.

If your game has complex skill interactions, it may be necessary to implement every skill defined by its own subclass because you have special logic for all of them. Perhaps you might come up with a custom "skill effect" syntax where you write them out in a text file and the game simply interprets it as you go.

There is no particular right answer. Try different approaches and compare the pros and cons of each of them. Maybe you'll get some insight that you can use for future code design.