Почему класс Collections содержит автономные (статические) методы вместо их добавления в интерфейс List?

Question

Для всех методов в Коллекциях , которые принимают List в качестве первого аргумента, почему эти методы не являются просто частью интерфейса List?

Моя интуиция такова: учитывая объект List, сам этот объект должен «знать», как выполнять над собой такие операции, как rotate (), shuffle () или reverse (). Но вместо этого, как программист на Java, я должен рассмотреть оба метода в интерфейсе List, а также статические методы "там" в классе Collections, чтобы убедиться, что я использую каноническое решение.

Почему некоторые методы были помещены как статические автономные методы в класс Collections, а не добавлены в интерфейс List (и предположительно, таким образом, реализованы некоторым существующим или потенциальным базовым классом)?

Я пытаюсь лучше понять проектные решения, лежащие в основе инфраструктуры коллекций Java.

Есть ли здесь какой-то убедительный принцип проектирования ОО, который я пропускаю? Или это различие было сделано просто по какой-то практической причине производительности?

Answer 1

Суть в том, что при наличии подходящих примитивных операций (удаление, установка и т. Д.) Куча более высокоуровневых операций (сортировка, перемешивание, двоичный поиск) может быть реализована один раз , а не реализована каждым отдельным списком. осуществление.

По сути, java.util.Collections похож на класс Enumerable .NET, полный методов общего назначения, которые могут работать с любой коллекцией, чтобы они могли совместно использовать одну реализацию и избежать дублирования.

Answer 2

Рациональное использование методов интерфейса List

1. Интерфейс List является очень важной частью среды выполнения Java и уже немного обременителен для полной реализации всех членов при развертывании ваших собственных реализаций List.,Таким образом, добавление дополнительных методов, которые не имеют прямого отношения к определению списка, является немного посторонним.Если вам нужны эти методы в реализации List, почему бы не создать подкласс интерфейса, а затем требовать их?
2. Если вы собираетесь встретиться, скажем, в версии 1.3 и добавить функциональность в интерфейс List, добавив новые служебные методы,вы сломаете все прошлые разработчики интерфейса.
3. С точки зрения управляемой доменом разработки служебные методы в коллекциях не являются частью обычного домена списка.
4. Относительно принципов проектирования ООЯ думаю, что было бы важно провести различие между ОО-разработкой приложения и ОО-средой исполнения на языке.

Авторы Java могут сделать вещи совсем по-другому, теперь, когда у них есть ретроспективный взгляд и перспективы на многие годыиспользование API.Тем не менее, интерфейс C # IList очень похож на Java, и авторы C # имели перспективу.

Answer 3

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

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

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

Answer 4

Здесь есть два объяснения:

1. История: класс коллекций был создан после интерфейса списка. Дизайнеры решили сохранить обратную совместимость уже существующего интерфейса. В противном случае многим разработчикам придется изменить свой код.

2. Логический: методы, о которых вы говорите, не требуют внутренних знаний о реализации List и могут быть реализованы через ЛЮБОЙ набор, реализующий его.

Answer 5

Это служебные методы, а не основные функции списка.Интерфейс List просто распухнет, если вы добавите каждую возможную операцию в List.И операциям в Коллекциях не нужно знать о внутренних объектах Списка, они работают на открытом интерфейсе, поэтому могут счастливо жить во внешнем классе.