Компаратор как статическое поле - интерфейс или реализация?

Question

У меня есть класс, который уже имеет «естественный» порядок, и вы хотите определить другой Компаратор, который можно использовать аналогично String.CASE_INSENSITIVE_ORDER - т. Е. Определить его как статическое поле, которое нужно указать при необходимости.

С интерфейсом Foo, который является фактическим типом сравнения (это будет Comparator<Foo>), я за его размещение вместо FooImpl (только одна реализация в этом конкретном случае, если это имеет значение). Он реализуется с использованием внутреннего класса, подобного строковому, за исключением того, что этот класс должен быть общедоступным, поскольку Foo является интерфейсом.

Удивление, если лучше помещать его в FooImpl вместо Foo, и если да, то почему? Кроме того, я не забочусь о публичной видимости класса реализации, но должен ли он быть отдельным отдельным визуализируемым объектом?

Answer 1

Если это специфично для интерфейса, введите интерфейс. Если это специфично для реализации, включите ее в реализацию. Это также имеет наибольший смысл. Текущее количество реализаций не имеет значения. В любом случае вы всегда можете обеспечить реализацию своего собственного компаратора, специфичного для реализации.

Answer 2

Является ли компаратор предназначенным для использования вне FooImpl? Если это так, вы можете просто поместить его в интерфейс, как и перечислить. Я бы не поместил его в FooImpl, если какой-либо код с использованием нового компаратора использует только интерфейс Foo.

Имейте в виду, что им не нужно знать о FooImpl только для использования компаратора.