Input is usually more abstracted from character behaviour than that.
Usually by some kind of "character controller" that translates requested state into movement/actions.
Ideally you don't want to couple that too closely to actual player input. What if in the future you want an AI behaviour tree to drive that entity? Or what if you implement networked multiplayer and you're simulating entities that are being controlled remotely?
The data a character controller is usually operating on is more closely tied to the actions that particular type of entity can perform (desired movement direction and speed, booleans to indicate whether or not particular actions are being requested, etc).
Personally for things like input, AI controllers, cameras etc, my preference is not to hang those directly off the entity itself, as you potentially might to make it more flexible to leave your options open. E.g what happens if you want to be able to dynamically switch the camera/control to another entity without destroying the old one, and have the old entity be taken over by AI? (Like in some team sports games, for example). What if you want to have a cutscene where the camera gets temporarily switched to a cinematic camera?
Collision detection and the like really don't belong on the input level. The best way to think about it in my opinion is that input is what the player/AI is asking to do. Whether or not it can do those things is irrelevant to the input system.