Advertisement

Interface Design | Contents | Previous | Next

Perhaps compare Iterator with LinkMap and ModifiableLinkMap, rather than having Removerator.

Optional Semantics

• Guideline: Avoid optional clauses in semantic contracts.
• The iterator interface from java.util:

  package java.util;
  
  public interface Iterator {
  
      // Returns true if the iteration has more elements.
      boolean hasNext();
  
      // Returns the next element of the iteration.
      Object next();
  
      // Removes from the underlying collection the last
      // element removed by the iterator (optional
      // operation).
      void remove();
  }
  

• What happens if you call remove() on an object that doesn't support it?

  You get an UnsupportedOperationException

• Thus, remove() could have been named, mightRemove()
• I have no way to know whether this object can remove() for me, without calling the method.

---

Why Avoid Optional Semantics?

• A type should mean: "what an object can do for me."
• Here's a different approach:

  package java.util;
  
  public interface Iterator {
  
      // Returns true if the iteration has more elements.
      boolean hasNext();
  
      // Returns the next element of the iteration.
      Object next();
  }
  
  package java.util;
  
  public interface Removerator extends Iterator {
  
      // Removes from the underlying collection the last
      // element removed by the iterator
      void remove();
  }
  

• Here, Removerator means an Iterator that can remove elements from the underlying collection
• Optional code is likely slower than types code, because throwing exceptions is slow
• Optional code robs you of strong typing at compile time that can help you catch errors sooner.
• Optional code has less meaning (less semantically rich) than types code (Inaccurate Menu)

---

Collections API Design FAQ

• Why don't you support immutability directly in the core collection interfaces so that you can do away with optional operations (and UnsupportedOperationException)?

  This is the most controversial design decision in the whole API. Clearly, static (compile time) type checking is highly desirable, and is the norm in Java. We would have supported it if we believed it were feasible. Unfortunately, attempts to achieve this goal cause an explosion in the size of the interface hierarchy, and do not succeed in eliminating the need for runtime exceptions (though they reduce it substantially).

  Doug Lea, who wrote a popular Java collections package that did reflect mutability distinctions in its interface hierarchy, no longer believes it is a viable approach, based on user experience with his collections package. In his words (from personal correspondence) "Much as it pains me to say it, strong static typing does not work for collection interfaces in Java."

  ...

  When all was said and done, we felt that it was a sound engineering compromise to sidestep the whole [exploding interfaces] issue by providing a very small set of core interfaces that can throw a runtime exception.

• Won't programmers have to surround any code that calls optional operations with a try-catch clause in case they throw an UnsupportedOperationException?

  It was never our intention that programs should catch these exceptions: that's why they're unchecked (runtime) exceptions. They should only arise as a result of programming errors, in which case, your program will halt due to the uncaught exception.

Perhaps use Place and ModifiablePlace as example, instead of Removerator.