Console keyboard input OOP

Question

I am trying to build a very simple console-based game with a focus on using OOP instead of procedural programming because I intend to build up on that code for more complex projects.

I am wondering if there is a design pattern that nicely handles this use case:

• There is a Player class with a MakeMove() method interacting with the board game.

The MakeMove() method has to somehow get the user input yet I do not want to code it into the Player class as this would reduce cohesion and augment coupling.

I was thinking of maybe having some controller class handle the sequence of events and thus the calls to keyboard input. However, that controller class would need to be able to handle differently the subclasses of Player (e.g. the AI class does not require keyboard input).

Thoughts ?

Answer 1

For web-UI work I'm fond of compositing the user-input/HTML-DOM interaction stuff as an easily decoupled component of a given object. Usually by taking all the .click and .focus and blur stuff for say a combo box and having it trigger the combo box object's revealOptions or selectOption methods or what have you. That way I can trigger actions/listen to events on the object with a nice details-independent and easily understood by non-UI web devs API while still having all of that object bundled into the same easily ported space.

Essentially, your Player would have an internal object that could be easily swapped out and whose job it is to communicate to the environment and likewise for giving the player ways to respond to tweaks in the environment in a generic way. In web-ui JS that interal object would listen to browser events and then trigger methods of the outer object's API we're fussing about internally. Then it would listen to generic outer object's events and handle all the HTML transformation junk the guy manipulating the player object doesn't want to fuss with just to move a checker or something.

It's basically two sets of APIs and listeners used to decouple but it's all plugged into the same thing. If you want to override for a new environment you could just make that internal object something that can be replaced when you hand off a different one in the constructor or class or whatever...