Inner classes in my interface - ok, no k, indifferent?

Question

I have an interface and a set of ComparatorS which are only used for objects which implement the interface. So I put the ComparatorS in the interface like so (not actual code because it is for my job):
public interface Abc {
  //Class loader should only do this once so they are basically singleton constants
  public static final Comparator C_1 = new C1();
  public static final Comparator C_2 = new C2();
  //... there is one more
  public String getSomething();
  public String getSomethingElse();
  //First Comparator inner class
  public class C1 implements Comparator {
     private C1(){ }
     //implements appropriate methods checking for instanceof Abc in the compareTo method
    //Compares something (using getSomething())
  /* Second Comparator inner class */
  public class C2 implements Comparator {
    //same thing
    //Compares somethingElse (using getSomethingElse())
} //End interfaceUsage:
Set s = new TreeSet(Abc.C_1);
s.add(abc1);Because the Comparator implementations were specific to objects which implement the interface I felt that was the best way to make that fact clear. If they were over in a separate package it would be confusing that these are for the one interface. If they were in the same package as Abc it wouldn't fit (IMO) because they are more utility type classes.
So it was either that or make them a singleton in their own class files or something like this and I found myself liking this.
Any comments on pros/cons of doing it this way?

Answer 1

I'm confused as to why it would make sense to put the
Comparators 'in' the interface but not in the package
with the interface. You can't put them 'in' the
interface without putting them in the package. In
reality, nesting them in the interface just creates
classes in the interface's package.My whole deal is that after talking it out I see that it is bad for reuse to have something which could be so generic residing in a particular interface (and therefore deduced soon after that in the same package as my interface). Which made me decide not to have the inner classes because it IS in the same package at that point. But I am saying that is bad. As I tried to state before, for the same reason I now think it is bad to have the classes in the interface (not much i.e. no reuse outside of the interface) then it is bad to have it in the same package as the interface (unelegant reuse outside of the package). Because if the getSomething() is getName() that could be used as a comparator for many different objects in different packages. I don't want to limit. This stance was a progression, once I decided not in the interface, I then also decided not in the same package.
Java is strongly typed. If the class isn't an
instance of the class you are casting to (in this
case the interface) it doesn't matter if it has a
method with the same signature. The cast will fail.Yes, of course, but like generics, you are not limited to just one type (Object is the type of the parameter). So I can either use instanceof before casting (not the best way) or I could have private overloads of the compareTo() method, a new one for every type I support and each supported type which has a getName() could come from a couple different packages. Not that generics does it the same way but on top of being about to declare hierachies that a genericized object can deal with you can also have comma delimitted other objects. They don't have to be related by package or hierarchy in generics. So I don't think it would be so bad for my Comparator to be (if it fit that these different types all had the same method needed by my Comparator).
>>
Here's anothe reason not to do that. Let's say that
someone is using the interface. They need to compare
it to something else, if the Comparators are right
there with the interface, they will be likely to find
them. If they are in some other package, they'd have
to know where to go look for them.If that is the case, where I was worried about easy to find then I would go back to using inner classes with each Comparator as a constant. If I was worried about ease of finding where these ComparatorS are over code reuse across packages.
I mean, I think if I am going to tie the ComparatorS so close to a particular Type then I am going to add it as an inner class whether my type was an interface or a class. At least that is what I am thinking now.
>
This is what I am talking about. So many Java
developers treat packages like filing cabinets. I
put things that do this here and things that do that
there. But this is actually not very useful and it
hamstrings your designs.
Java doesn't have a friend class syntax like C++. So
there's no way to say this class over here has access
to this but no one else does. These kinds of
relationships are very desireable. Some classes will
need to access things in another class that shouldn't
be public. You can do this cleanly if they ae in the
same package but not otherwise.But I am not talking about taking an abstract class putting it in pack1 an a subclass in pack2. I am talking about putting a utility class that could eventially work on 50 classes in a place that is playingfield neutral and not in the original type it deals with today only. I am dealing with public accessor methods on my objects.
>
For example. Let's say you want to create a Factory
(I'm using Factory in a loose way here not
necessarily a GoF Pattern) for a public class. You
don't want every class to have access to contructor
because it creates the Object without initializing
all the necessary atttributes. The factory is
specially crafted to do this with protected info and
access rights. If you put the class and the factory
together it;s a snap. You create a package-protected
constructor, some package-protected methods and/or
fields and do it. No class outside the package will
be able to do these dangerous operations. How do you
do this if you have a factory package and a data
object package?That is a whole nother situation I think. In that case it is obvious. I thought my situation was a little less obvious because of the utility nature of the classes (ComparatorS) that I was dealing with.