Question

Recently, I have been writing many classes which have, apart from generic variant, some primitive variants, for example Foo<T>, IntFoo, DoubleFoo etc. First, I used to put every variant in separate files but I soon found out that the package content has become unreadable due to large number of classes with similar names. On the other hand, putting those in a separate package often results in a loss of cohesion and extra dependencies between packages.

In the meanwhile, I have come to the idea to have the following structure:

public class Foo {
    public static class TypeFoo<T> { ... }
    public static class IntFoo { ... }
    public static class DoubleFoo { ... }
    ...
}

or

public class Foo {
    public static class Type<T> { ... }
    public static class Int { ... }
    public static class Double { ... }
}

I am interested in two things:

1. Does any of these two approaches result in greater overhead when using only one inner class (e.g. int-variant of the class), compared to one-class-per-file approach? Does this overhead, if any, applies when there are inner interfaces instead?
2. Which of these two approaches is better, if any, or if none is good, what are the alternatives?

Answer 1

inner classes will be more of a pain in the long run, in my opinion. if you look at the way Microsoft named their animation classes, they had the same dilemma that you did. They chose to have tons of different classes, but as a consumer of these I have found that I prefer it to be this way.

to answer your first question, there should be no overhead. When java compiles inner classes it separates them into separate *.class files anyway, so in the end the result is the same. During compilation the parser will have to sift through a lot of Foo.* references but the extra time would be negligible.