Object diagrams, sharing, and exceptions

The key concepts for this recitation are those of object diagrams, especially the way fields in objects can lead to sharing of references, and also the way exceptions can provide handling of special cases.

• First consider the code provided. Consider the object diagram representing the state of the system just before the execution of t.challengeBy(p2). This has a tournament object t with a vector players whose elements are p1 and p2, and champ refering to p1. The player p1 has myItems containing i1 and i3, and score with value 9. In contrast p2 has only one item (i2) in its myItems collection, and its score is 6. i1 and i3 each have owner refering to p1, while i2 has owner refering to p2. The value fields in the items i1, i2 and i3 are respectively 5, 6 and 4. Trace the effect of t.challengeBy(p2), and show the object diagram for the state after the call. Also, draw an object model for this system (recall that an object diagram shows individual object instances, while an object model shows the sorts of objects, ie classes).
• This system is intended to have the property that the owner field in Item provides inverse information to the myItems field in Player. That is, for any player p, the entries in p.myItems should be exactly the set of all Items i such that i.owner == p. Write a method in Tournament that will check whether or not this is true.
• Identify situations in the code given where a method call on an object could lead to a run-time problem or unexpected result. Note that we require that some methods have non-null arguments, so don't consider situations which only arise when this requirement is violated. Hint: find code that seems vulnerable to run-time error like NullPointerException or ArrayIndexOutOfBoundsException, and then try to mentally trace backwards to see whether this error can actually arise. For example, in the win() method of Item is a call with target owner, so we wonder if owner might be null. In fact, owner is initialised to a non-null value at construction, and only changes to other non-null values (in method body of transfer). So this call is safe.

  For each situation, suggest how best to deal with this (for example, you might throw an exception, or simply guard the vulnerable code by an "if" statement). If you suggest using an exception, say: whether the exception should be checked or unchecked, where the exception should be thrown, where it should be caught, and what should happen then.

• The Vector class has a method contains, which takes an Object as argument, and returns a boolean saying whether or not the object is one of the entries in the Vector. This method is redundant, as we could achieve the same effect in the client, with a loop traversing the vector. There are two possible ways to treat the idea of "the argument is an entry". These correspond to reference equality between argument and entry, or value equality. These correspond to cliches

  for (int i = 0; i< vect.size(); i++) {
      if (target == vect.elementAt(i)) {
          return true;
      }
  }
  return false;
  

  and

  for (int i = 0; i< vect.size(); i++) {
      if (target.equals(vect.elementAt(i)) {
          return true;
      }
  }
  return false;
  

  Design a test case which will allow you to say which meaning the Vector class follows.
• Someone wants to extend the competition system by a method in Player which will give every one of the player's items to someone else. Fred Foolish proposes the following code

  public void surrenderTo(Player p) {
      transferAll(myItems, p);
  }
  
  private static void transferAll(Vector v, Player newOwner) {
      for (int i = 0; i < v.size(), i++) {
          current = (Item)(v.elementAt(i));
          current.transfer(newOwner);
      }
      v = new Vector(); // make v empty
  }
  

  Explain what is wrong with this. In particular, distinguish whether: this won't work; or it will work but it's a bad design.