You will use and extend this framework in a number of upcoming labs and assignments that allow users to solve various problems.

For this course, you will sometimes be asked to download and execute a particular jar file, for example, foo.jar.

Note: Depending on your browser, you may get a warning about downloading and executing files like this. In general, you may want to avoid downloading jar files from sources you do not trust.

In order to run a jar file on a machine:

• The JDK (Java Development Kit) must first be installed.
• On some operating systems, you may be able to run a jar file simply by double-clicking its file icon.
• Otherwise, you will need to open a terminal console window and execute the command:

  	    java -jar foo.jar	

To see how they are used, refer to the Introductory Video (mp4) for this module.

For example, in the farmer, 8-puzzle, and one-way streets problems,

• There is a fixed number of problem states
• There is a fixed number of well-defined possible moves
• The problem is to transform the current state into a goal
• The structure of the user interfaces is similar

A framework manages repeated code so that it can be shared among multiple applications.

The current types involved include both abstract and concrete classes. Other types will be added as the framework is developed.

The types are further divided into these sub-packages:

• framework.problem
• framework.solution
• framework.ui

Note that the code presented in this framework is generic in the sense that:

• Its terminology does not mention application domains involving farmers, goats, 8-puzzles, one-way streets, etc.
• Instead, the concepts used (states, problems, consoles, etc.) are generally applicable to any application domain; therefore the code using these concepts is also applicable to multiple domains and thus reusable.

These types are State, Mover, and Problem.

Since this concept is to range over widely differing application domains, we create an abstract class type called State. Extending classes will encapsulate the representation details of concrete problem states.

This type does not depend on any other type within the framework, so its UML model is simple and looks as shown below. The class code is shown in State.java.

• A State object holds the string naming the move that produced it. Methods for accessing the move and producing the state's heuristic value (discussed later in the course) are included.
• Extending classes are expected to override the toString and equals methods, inherited from the Object superclass.

addMove:

• The type of the second argument to addMove, UnaryOperator<State>, is a functional interface, or interface with exactly one method. (UnaryOperator<T> is defined in the library package java.util.function.)
• That method must take an argument of type State and return a value of type State.
• Each move name for a problem application domain will be associated with a functional object implementing the UnaryOperator<State> interface on a hash map for constant-time look-up. A hash map is a kind of hash table, a data structure that will be discussed later, but if interested see Hash Tables on the menu.

• When the user tries a move, the doMove method is called, which uses the move name given as its first argument to look up the functional object on the hash map and apply its single method, functionally, to the state given as doMove's second argument.
• If doMove successfully creates a new state, setMove is called on it to set the move name that resulted in the state.
• Functional objects, or instances of functional interfaces, can be specified in Java 8 through lambda expressions. Examples are given in Using the Framework (see menu). Lambdas will be discussed in more detail later, but if interested see Lambdas on the menu.

Getters and setters are provided for the problem name and introduction, the initial, current, and final States of the problem, and the problem's associated Mover object.

Since it stores various states and the mover object, Problem aggregates State and Mover objects, as shown below. The class code is shown in Problem.java.

The class is not abstract, but it can be subclassed, especially if the success method needs to be overridden.

It extends the Console class (from previous exercises) and overrides its handleInput method to get move options from the user, check move legality, and update the display, which is entirely text-based, using strings.

A ProblemConsole object aggregates a single Problem object and a corresponding SolvingAssistant object, as shown below. The class code is shown in ProblemConsole.java.

It tries moves, updates the current state as necessary, keeps track of the move count, and checks whether the problem has been solved.

These responsibilities require that SolvingAssistant contain a Problem object, as shown below. The class code is shown in SolvingAssistant.java.

• DummyState: extends the State class
• DummyMover: extends the Mover class
• DummyProblem: extends the Problem class
• DummyProblemTest: uses the ProblemConsole class to create a JavaFX application

To see how it is used, refer to the Using Framework Video (mp4) for this module.

Although the application does not do much, it demonstrates the features of the framework:

• Move options 1–4 update the current state display
• Move option 5 demonstrates an illegal move
• Move option 3 demonstrates success

Note that the classes are in a package called domains.dummy.

• The only content of a DummyState is a string that is displayed in an enclosing box
• The toString method uses a StringBuilder to display the content string
• The equals method simply checks for the equality of a state's content string with that of its argument:
  • Since the argument parameter is of type Object, it must be cast to DummyState
  • Note the use of the equals method built into the String class
  • The hashCode method will be explained later in the course

Running the DummyProblemTest class produces the application shown in the screen shot.