If you're dealing with small games, this is somewhat inconsequential, as a finished game is better than a well-engineered game.
That said, if you're already finding yourself wishing that you could switch back and forth between screens, or set an option on one screen which propagates to another screen, afterwards, then I'd suggest looking into something like a
"Mediator" / "Moderator" pattern.
The idea is that you have one system-wide object (or domain-wide object), which can be called by all members of that system/domain.
subscribe/listen/"on" + <event> to this object.
When that happens, you register a method or a function to use as a callback, to act on parameters passed in with the notification.
var system = Moderator(),
player = Player(),
scoreboard = Scoreboard();
player.suicide(); // system.notify("player-kill",
// /* dead-player */ player.id,
// /* killed-by */ player.id );
Now, instead of finding ways of tying everything together, you're dealing with custom events, the names of which you name, followed by agreed-upon types and numbers of function parameters...
The disparate parts don't know anything about one another.
So when you make a multiplayer character, you might use a moderator as a way of registering to receive network updates.
If you kill that multiplayer character, it doesn't really need to update its network position any more, so you can unregister it from the moderator.
A player character who gets knocked-out or stunned for a short time might also be unregistered from receiving controller updates.
Once your components are this loosely coupled there are all kinds of things you can do.
You might also have, say, an achievement system and a goodie-unlock system which listen for your kills, and unlock after you reach X.
Now, instead of having to be hard-coded into the middle of your player class, they can just listen to the same moderator, to be notified of the same event.
You could also have multiple moderators...
For component-based stuff, this is usually the half-way between OOP and 100% entity-system.
For example, you might have every player have their own internal moderator.
That moderator might be the talking point between each of the components (like when a control tells the movement to jump, tells the skeleton to change animations, tells the IK-engine to blend the jump in with whatever you were doing, etc)...
...and then the player might be given access to a "global" moderator (or one which manages ALL players).
And that moderator would handle all communication from the player(as a whole) as it needed to be broadcast to the outside world.