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

Question

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

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

Хотите знать, лучше ли поместить его в FooImpl вместо Foo, и если да, то почему? Также меня не волнует общедоступная видимость реализующего класса, но должна ли это быть отдельная видимая сущность отдельного пакета вместо этого?

Answer 1

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

Answer 2

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

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