Java: структура кода и именование классов вариантов примитивного типа - лучшие практики

Question

В последнее время я пишу много классов, в которых, кроме общего варианта, есть несколько примитивных вариантов, например, Foo<T>, IntFoo, DoubleFoo и т. Д. Сначала я использовал каждый вариант в отдельных файлах, ноВскоре я обнаружил, что содержимое пакета стало нечитаемым из-за большого количества классов с похожими именами.С другой стороны, помещение их в отдельный пакет часто приводит к потере сплоченности и дополнительным зависимостям между пакетами.

В то же время я пришел к мысли иметь следующую структуру:

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

или

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

Меня интересуют две вещи:

1. Приводит ли какой-либо из этих двух подходов большие издержки при использовании только одного внутреннего класса (например, int-варианта класса), по сравнению с подходом "один класс на файл"?Применяются ли эти накладные расходы, если таковые имеются, когда вместо них есть внутренние интерфейсы?
2. Какой из этих двух подходов лучше, если таковой имеется, или если ни один не хорош, каковы альтернативы?

Answer 1

внутренние уроки будут более болезненными в долгосрочной перспективе, по моему мнению. если вы посмотрите, как Microsoft назвала их классы анимации , у них была та же самая дилемма, что и у вас. Они решили иметь тонны разных классов, но как потребитель их я обнаружил, что предпочитаю, чтобы это было так.

чтобы ответить на ваш первый вопрос, накладных расходов не должно быть. Когда java компилирует внутренние классы, он все равно разделяет их на отдельные *.class файлы, поэтому в итоге результат остается тем же. Во время компиляции парсер должен будет просмотреть множество ссылок Foo.*, но дополнительное время будет незначительным.

Answer 2

Может совершенно не иметь отношения к тому, что вы делаете, но вы можете рассмотреть возможность замены всех этих классов шаблоном Builder (или иначе известным как Fluent Interface ).Если эти классы реализуют универсальный интерфейс, вам не нужно никуда их выставлять, и вы все равно можете хранить их внутри одного класса построителя.

Хорошим примером этого будет MapMaker , который, вероятно, имеетМиллион различных внутренних классов, но единственное, что вас волнует, - это экземпляр Map или ConcurrentMap, который вы получаете из него.