1. Think about which additional fields and types it needs to implement the promised functionality.

2. Write a constructor FreeCellController(Readable rd, Appendable ap). Readable and Appendable are two existing interfaces in Java that abstract input and output respectively.

   Your controller should accept and store these objects for doing input and output. In the game, whenever you need take user input, use the Readable object and whenever you wish to transmit output, use the Appendable object.

   Look at the Readable and Appendable interfaces to see how to read from and write to them. Ultimately you must figure out a way to transmit a String to an Appendable and read integers and strings from a Readable object. The Scanner may offer a way out.

3. The void playGame(List<K> deck, IFreeCellModel<K> model, int numCascades, int numOpens, boolean shuffle) method should, obviously, play a game. To do so, it should ask the provided model to start a game with the provided parameters, and then “run” the game in the following sequence until the game is over:

   1. Transmit game state to the Appendable object exactly as the model provides it.

   2. If the game is ongoing, wait for user input from the Readable object. A valid user input for a move is a sequence of three inputs (separated by spaces or newlines):

      1. The source pile (e.g., "C1", as a single word). The pile number begins at 1, so that it is more human-friendly.

      2. The card index, again with the index beginning at 1.

      3. The destination pile (e.g., "F2", as a single word). The pile number is again counted from 1.

      The controller will parse these inputs and pass the information on to the model to make the move. See below for more detail.

   3. If the game has been won, the method should transmit the final game state, and a message "Game over." on a new line and return.

   Key points:

   • The deck: The deck to be used is the one provided as input, and not necessarily the one returned from the model. (Why is this very important?)

   • Quitting: If at any point, the input is either the letter 'q' or the letter 'Q', the controller should write the message "Game quit prematurely." on a separate line to the Appendable object, and return.

   • Invalid game parameters: If the game parameters are invalid (e.g., invalid number of cascade/open piles) and the model throws an exception as a result, the controller should transmit a message "Could not start game." and return

   • Bad inputs: If an input is unexpected (i.e. something other than 'q' or 'Q' to quit the game; a letter other than 'C', 'F', 'O' to name a pile; anything that cannot be parsed to a valid number after the pile letter; anything that is not a number for the card index) it should ask the user to input it again. If the user entered the source pile correctly but the card index incorrectly, the controller should ask for only the card index again, not the source pile, and likewise for the destination pile. If the move was invalid as signalled by the model, the controller should transmit a message to the Appendable object "Invalid move. Try again." plus any informative message about why the move was invalid (all on one line), and resume waiting for valid input.

   • Error handling: The controller should throw an IllegalStateException if either of its Readable and Appendable objects have not been initialized (i.e. if they are null). It should throw an IllegalArgumentException if a null deck or model is passed to it. The controller should not propagate any exceptions thrown by the model to its caller.

4. Write sufficient tests to be confident that your code is correct. Note: once the model has been tested thoroughly (which you did on Assignment 2...right?), all that remains to be tested is whether the controller works correctly in all cases.

Be sure to properly document your code with Javadoc as appropriate. Method implementations that inherit Javadoc need not provide their own unless their contract differs from the inherited documentation.