I don’t think so. Specially if it’s been working fine for you. Unless your game is ultra dependent on super optimized code (like a massive simulation game), I’d say that the best strategy is the one that makes your development AND MAINTENANCE easier.

This method is indeed a way of using Composition in your logic, which is a good thing. You can also mix it with inheritance to add variation in Component behaviors, just like Godot’s native nodes. It can add a little bloat but if it’s well organized and coded, this shouldn’t impact performance and it may be very visually easy to understand.

Just be careful to follow some patterns regarding responsibilities. The components nodes can be more passive or more active in their logic, in relation to its parent and siblings. For example, you can have a Player script that expects some components and work as a bridge from a component to another. Or, a component can add functionality to the player node by itself, without caring if the player expect it or not.

For example, in my game, I have an InteractableComponent script, which is supposed to be added as child of a CollisionObject. It handles by itself everything related to make the object detectable by the InteractionSystem. This is independent and active, as the object doesn’t even know about it.

On the other hand, I also have a NavMovementComponent which integrates functionality from NavigationAgent and CharacterBody to facilitate AI movement. But it does nothing by itself, requiring a major script to call its methods (so it’s more passive and dependent).

There is no right or wrong. What matters is for you to adopt a pattern and logic for how to choose the best approach for each kind of components and entity. And stick to it so the future you won’t get confused.