It shouldn't cause any unit test difficulty, as long as the anonymous
class capabilities are limited to those specified by the Comparator
interface. If the anonymous class has any extra functions, the unit test
would need to use the actual type to access them.

Patricia

On Tue, 28 Jun 2005 07:47:41 -0700, kk_oop wrote:

I'd always use named classes, just for the sake of readability, but in
principle, there is nothing wrong with an anonymous Comparator.

I'd be more precise, and say that the question is whether to use a named
*concept* or not.  The use of an anonymous class is just an
implementation choice.  For example, I sometimes do something like this:

class Foo
{
   public static final Comparator<Foo> SOME_COMPARATOR
       = new Comparator<Foo>() {
           @Override
           public int compare(Foo a, Foo b)
           {
               ...
           }
       };
}

Even though there is an anonymous nested class (though not strictly an
inner class) being used there, the concept that it represents definitely
does have a name.  This is easy to unit test even if the concept is non-
trivial.  On the other hand, a truly on-the-fly Comparator such as:

   List<Foo> foos = ...;
   Collections.sort(foos, new Comparator<Foo>() { ... });

would need to meet a stricter standard of triviality of content, because
you don't get the chance to use an identifier to sum up the abstraction,
and you don't get the ability to reference the concept in and of itself.  
Only the code itself expresses your intent, so the code had better be
pretty obvious, to the point that a unit test would be superfluous.

Because most simple Comparator instances do not have state, I would not
favor exposing a named nested class for a Comparator implementation.  
Instead, I'd do as in the first example above; expose a named instance
of the class.