Usually, it pays off to keep visualisation code separate from code for state and logic, where visualisation depends on state and state is unaware of visualisation. However, sometimes the development workflow is far more convenient when state depends on a bit of visualization. For example, we transition to a different state once an animation is finished, or we activate a hitbox for particular frames of an animation. This strongly couples state and animation. Is this a trade-off that is often considered worth it?

To illustrate, here's my situation:

I started out with a character controller with Idle and Moving states. The controller has public getters for its state and its facing direction. Separate character animator code makes sure to play the correct animation based on those two pieces of information. The controller does nothing animation-related.

Now, I'd like to introduce usage of a tool to the character controller. Different tools might have animations that take different amounts of time (casting out a fishing rod versus swinging a sword). I could stick to my state-visualisation separation and define durations for tool usage, separate from the animations. However, it will be painful and error-prone to keep tool usage duration and tool usage animation length in sync. I don't want to have two definitions for virtually the same thing. Continuing this idea for activation and deactivation times of a hitbox will be even more of a pain, since it will be hard getting these times to match with particular frames of an animation.

Alternatively, I could make use of the length of an animation clip or an animation-end event in the character controller. I could also make turning a hitbox on and off part of animations that need a hitbox. This workflow makes sure I don't repeat myself and feels very intuitive. However, this means I will have to handle or at least know about animation within a class that is responsible for controlling the character. This breaks single responsibility principle and this controller class might therefore grow into a large monstrosity trying to handle both state and visualization.

Do you think mixing state/logic with visualisation is the way to go in such a character controller? And if so, how would you set things up to prevent this character controller code from exploding in size and complexity?