Outline of Class 37: Ordered Structures

Miscellaneous

• It sounds like we'll need to spend a little time on assignment six, assignment seven, and assignment eight.
• If you'll need more time on the assignments, please let me know.
• Reminder that there's no class tomorrow.
• I will be in all day Wednesday and back again Wednesday evening (7:30 to 10:00 or so).

Unplanned Discussion

• There was a reasonable amount of unplanned discussion at the beginning of class, mostly related to the current homework assignments, but also to issues that came up during work on those assignments.
• Thanks to Andrew Vick for the extra notes used to put this back together.

Designing and Using a Move Class

• There was a question as to what goes in the Move class.
• SamR suggested that what you really need is a Puzzle and Move interface.
• In the Puzzle interface, you'll need to support the functions that we've used in our generic puzzle solver routines.
• Here's a sketch

  /** A simple puzzle. */
  public interface Puzzle {
    /** List all the legal moves from the current state. */
    public Iterator moves();
    /** Make a legal move */
    public void makeMove(Move m) throws Exception;
    /** Reset the puzzle to its initial state */
    public void reset();
    /** Check if the puzzle is solved. */
  } // Puzzle
  

• Now, you'll then want to each puzzle you develop to implement this interface.
• What should go in the Move interface? Well, since moves are puzzle-specific, perhaps nothing.
  • Why do we want such an interface? So that we can include makeMove(Move m) in our Puzzle interface.
• Here's a sample move class for the coin puzzle ...

  package coinpuzzle;
  ...
  public class CoinPuzzleMove implements Move {
    /** The position of the coin that we're moving. */
    int position;
    /** The direction in which we're moving it.
    int direction;
  } // CoinPuzzleMove
  

• We can now use it in our CoinPuzzle class

  package coinpuzzle;	// Permit direct access to the fields of the move
  ...
  public class CoinPuzzle implements Puzzle {
    ...
    public void makeMove(Move m) throws Exception {
      CoinPuzzleMove cpm;
      // Convert the move
      if (m instanceof CoinPuzzleMove) {
        cpm = (CoinPuzzleMove) m;
      }
      else {
        throw new Exception("Illegal type of move");
      }
      // Verify that the move is legal
      if (!legal(cpm)) {
        throw new Exception("Illegal move");
      }
      // Make the move
      coin = topCoin(cpm.position);
      removeTopCoin(cpm.position);
      placeCoin(coin,newPosition(cpm.position,cpm.direction));
    } // makeMove
    ...
  } // CoinPuzzle
  

Interfaces vs. Superclasses

• The use of interfaces led to a question on the relationship of interfaces and classes.
• In some sense, an interface is a class without fields or bodies for methods.
• Like a class, an interface permits some form of subclassing (using implements instead of extedns).
• Like a class, an interface goes in a separate file.
• However, a class that implements an interface must define all of the methods in the interface, rather than just inheriting them.
• Why do we do this? Because one of the reasons we use subclassing is to write generic operations and structures that can use a variety of types of arguments.
  • For example, once we've written one Stack class that works on Objects, we can use it for any subclass of Object.
  • Similarly, once we've written one sort() routine that works for any list of comparable objects, we can use it for any comparable objects.
• There are other reasons for using subclassing, such as inheriting code. Interfaces don't support them.
• Why have interfaces? Because Java permits only single inheritance, so when you want to use the same class in multiple ways, you can't do it with multiple inheritance.
  • Instead, you can use interfaces.

Static vs. Nonstatic Methods

• There was a note that Java frequently reports "cannot call nonstatic method from static method" (or some such). What's going on here, and is the solution just to insert static before the callee?
  • Do not just insert static!
• In Java, many methods need to access the fields of an object, and thereby require objects in order to execute. This is the standard for methods.
• However, there are also methods that are somewhat "independent" of the objects.
  • For example, a function that converts a String to an integer probably belongs in the Integer class, but doesn't have an associated Integer object.
  • Similarly, the main() method is associated with the class as a whole, but not with particular objects in the class.
• Methods that are associated with the class as a whole, but not with a particular object are called "static" methods and require the static keyword.
• There are some restrictions on the interrelationship of static and nonstatic methods.
  • Static methods can call other static methods.
  • Nonstatic methods (those associated with objects) can call static methods.
  • Nonstatic methods can call other nonstatic methods.
  • However, static methods cannot directly call nonstatic methods.
• Why that last restriction? Because it makes no sense to call a nonstatic method without referring to the corresponding object!
  • Consider a call to value(). What value are you requesting? The value of the last object you used? The value of some random object? Something completely different.
• So, when Java complains about you calling a non-static method from a static method, you should think about what you were really intending ...
  • Perhaps you needed to associate the non-static method with a particular object.
  • Perhaps the calling function should have been non-static.
  • Perhaps the called function should have been static because it used only static fields and called only static methods.
• Note that it is safe for any method to call the method of any object, as long as it specifies the object. The preceding discussion assumes that objects aren't mentioned explicitly.

Ordered Structures

• Recall that in our discussion of linear structures, we suggested that there could be a number of policies for determining which element is removed. These included FIFO (first in, first out) and LIFO (last in, first out).
• In an ordered structure, the element removed is the least (or, perhaps, greatest) element in the structure.
• As in our design of other structures, we need to consider the efficiency of the various operations.
  • It may be a goal of the data structure designer to make removeLeast() as efficient as possible.
  • It may be a goal of the data structure designer to make insert() as efficient as possible.
  • It may be a goal to balance the various methods
  • or ...
• The design choices may be illustrated by an attempt to create an OrderedVector class.
• We could ensure that the elements in the vector are always in order (smallest to largest), so that removeLeast() removes the first element.
  • insert() is then an O(n) operation as we may have to shift all the elements to insert an element in the "correct" place.
  • removeLeast() is also an O(n) operation, as we need to shift everything left after the removal.
• We could ensure that the elements in the vector are always in order (largest to smallest), so that removeLeast() removes the last element.
  • insert() is still an O(n) operation as we may still have to shift.
  • removeLeast() becomes an O(1) operation.
• We could leave the elements in the vector unordered, and run a min() routine to find the smallest element.
  • insert() is either O(1) or O(n), depending on whether or not we have to grow the vector.
  • removeLeast() is now an O(n) operation.