10/28 Recitation 8 - Tying Up Loose Ends

1. The checkRep() Paradox
2. The Comparator Contract
3. Anonymous Classes
4. MouseAdapter

1. The checkRep() Paradox

public class ExampleMap implements java.util.Map {

  /*
   * RI =
   *  (1) size is equal to the total number of Entry
   *   objects in, or linked to by members of, the buckets array
   *  (2) size >= (0.25 * buckets.length)
   *  (3) size <= (0.75 * buckets.length)
   */

  private int size;

  private Entry[] buckets;

  private static final boolean CHECKREP_ENABLED = true;

  private void checkRep() {
    if (!CHECKREP_ENABLED) return;
    if (size < (buckets.length / 4)) {
      throw new RuntimeException("number of buckets " + buckets.length +
        " is too large for number of entries: " + size);
    }
    // checks for other conditions of RI
  }

  public ExampleMap() {
    size = 0;
    buckets = new Entry[8];
    checkRep();
  }

  public int size() {
    checkRep();
    return size;
  }

  public Object remove(Object key) {
    checkRep();
    try {
      if (!containsKey(key)) return null;
      Entry oldEntry = removeEntryForKey(key);
      return oldEntry.getValue();
    } finally {
      checkRep();
    }
  }

  private Entry removeEntryForKey(Object key) {
    // removes entry from buckets and returns it
    // side-effect: updates size field if Entry removed
    // calls checkResize() before returning
  }

  private void checkResize() {
    if (size() < (buckets.length / 4)) {
      rehash(buckets.length / 2);
    } else if (size() > (3 * buckets.length / 4)) {
      rehash(buckets.length * 2);
    }
  }

  private void rehash(int newSize) {
    // resizes the number of buckets
    // and reassigns each Entry in the old buckets array
    // to its new bucket
  }

  // other public methods required to implement Map
}

Map map = new ExampleMap();
map.put("1", "Mississippi");
map.put("2", "Mississippi");
map.remove("2");

1. Temporarily Disable checkRep()

   One option would be to rewrite checkResize() as follows:

     private void checkResize() {
       boolean oldCheckRepValue = CHECKREP_ENABLED;
       try {
         CHECKREP_ENABLED = false;
         if (size() < (buckets.length / 4)) {
           rehash(buckets.length / 2);
         } else if (size() > (3 * buckets.length / 4)) {
           rehash(buckets.length * 2);
         }
       } finally {
         CHECKREP_ENABLED = oldCheckRepValue;
       }
     }
   

   This is verbose and inelegant. Furthermore, if the contents of your try block invoke other methods where it is important that checkRep() is enabled, then you may allow subtle bugs to creep into your code. This is dangerous and is not a good choice.
2. Use the size Field Directly

   Another option is to refer to size instead of invoking size() to avoid the side effect of invoking checkRep(). This is somewhat undesirable because it eliminates the abstraction that the size() method provides. For example, size() does something simple right now, but if it is changed to do something complicated later, then referencing size directly may miss those effects, which may be important. Furthermore, it is better to use size() to access the field in case someone extends ExampleMap and overrides the size() method to do something important every time the size field is accurate. For something as simple as size, this may not seem so critical, but it is possible to create other scenarios in which this may be a problem.

3. Create a Private Method to Access size() The best alternative seems to be to create a private accessor method for size that is used by size():

   public int size() {
     checkRep();
     return _size();
   }
   
   private int _size() {
     return size;
   }
   
   private void checkResize() {
     if (_size() < (buckets.length / 4)) {
       rehash(buckets.length / 2);
     } else if (_size() > (3 * buckets.length / 4)) {
       rehash(buckets.length * 2);
     }
   }
   

   This doesn't help those clients who override ExampleMap.size(), but it does allow all accesses to size to be updated in one place within ExampleMap. This is certainly cleaner than toggling the CHECKREP_ENABLED field, and it eliminates duplicate code. This is likely the best solution to the Paradox.

2. The Comparator Contract

3. Anonymous Classes

public class SurpriseComponent extends JComponent {

  private String message;

  SurpriseComponent(final String secretMessage) {
    addMouseListener(new MouseListener() {
      public void mouseClicked(MouseEvent e) {
	JOptionPane.showMessageDialog(getParent(), secretMessage);
      }
      public void mousePressed(MouseEvent e) {}
      public void mouseReleased(MouseEvent e) {}
      public void mouseEntered(MouseEvent e) {}
      public void mouseExited(MouseEvent e) {}
    });
  }

}

1. It eliminates the need to create arbitrary classes.
Suppose Java did not have anonymous classes. In that case, every time we wanted to add a MouseListener to a GUI widget, we would have to create a new class that implements the MouseListener interface.

2. It minimizes the scope of local variables (as Bloch advocates).
If there were no anonymous classes, and small helper classes had to be created to implement listener interfaces all over your code, then it would be possible to instantiate those helper classes from parts of your code that have no business instantiating that helper class. Using an anonymous class limits the scope of the class, making it impossible to instantiate outside the block in which it is created. This also makes your code easier to maintain because it is one less private class whose API he needs to be kept up to date.

Note that the parameter to the SurpriseComponent is declared final (the code would not compile otherwise). Normally, the secretMessage parameter would fall out of scope once the end of the block is reached; however, the anonymous MouseListener still exists when the end of the block is reached (because SurpriseComponent has a reference to it), so a reference to secretMessage needs to be persisted in some way. One way to resolve this problem is to declare the parameter final.

Alternatively, secretMessage could be assigned to the private field message and then message could be used as the parameter to showMessageDialog. Though this does not involve the use of the final keyword, the reference to message is persisted because it is a field of SurprisePanel. Another option would be to create a final local variable:

  SurpriseComponent(String secretMessage) {
    final String m = secretMessage;
    addMouseListener(new MouseListener() {
      public void mouseClicked(MouseEvent e) {
	JOptionPane.showMessageDialog(getParent(), m);
      }
      ...

4. MouseAdapter

public class SurpriseComponent extends JComponent {

  SurpriseComponent(final String secretMessage) {
    addMouseListener(new MouseAdapter() {
      public void mouseClicked(MouseEvent e) {
	JOptionPane.showMessageDialog(getParent(), secretMessage);
      }
    });
  }

}

This trick is used often in the java.awt.event package: KeyAdapter, MouseAdapter, MouseMotionAdapter, and WindowAdapter are just a few examples of classes with trivial interface implementations. Each adapter has an analogous listener interface in the same package that it implements.

Ironically, this is not a true use of the Adapter design pattern, as these adapters do not convert the interface of one class to that of another.