Overview

The text adventure game you made has been popular with the focus groups, so Acme Games wants you to rework your architecture, so that it is as easy as possible to add new states. They've hired a consultant who tells them that using inheritance and polymorphism will allow adding new states easily, so that's what you need to use. To prove the architecture, you need to convert your previous text adventure into one that uses inheritance and polymorphism as described below. If you did not complete something in Lab 2, finish that now, too.

Details

To prove the inheritance based state machine architecture, you must do the following: 1) Rework your state machine design to use inheritance and polymorphism 2) Add another dozen states to the game to show the amount of work required

Using Inheritance and Polymorphism in State Machines

The benefit of using inheritance and polymorphism is that you can write code to work with the more general case, and hide the details inside subclasses. A natural way of doing that for state machines is to have a State superclass and a specific subclass for each state in your game. Write the main loop of your state machine to work just with State. There should only be one place that you need to know about the specific subclasses, and that's where you create the instances of the specific subclasses. You will need to store those in an array of States, and reference them as needed during state transitions. This means that your State class will need to know what menu options the user should have when it is active, and should also have a method for telling it which option the user chose. But remember that the State is a Model class, so should not have any user input or output. Have it return an array of Strings for the menu options, for example. The View class can format those strings and display them to the user, and get the user's input. You should also still have a Model class that keeps track of the current state and any boolean variables. For this to work well, you should have a single state machine for the entire program, not a bunch of smaller state machines. Storing Enums To Files You might find it useful to store an enum in a file. You can write an enum to a file using something like: output.println (enumValue); and then read it again using something like: enumValue = EnumValue.valueOf(input.nextLine ()); where EnumValue is an enum, and enumValue is a variable of that type. Methods & Unit Testing You must use continue to use methods and unit testing of those methods in this lab. While much of the View/Controller class cannot easily be unit tested, you should be designing many of your methods so that you can unit test them (such as the menu formatting method). And all of the methods in the Model classes should be fully unit tested. You must use JUnit unit tests. What You Turn In Turn in two .java files for each class you design. One with the class itself, and one with the unit tests for that class. Also turn in the state machine diagram for your program and the UML diagram for both your Model class(es) and your State hierarchy