Почему класс Наборов содержит автономные (статические) методы вместо них добавляемый к интерфейсу List?
Для всех методов в Наборах, которые берут Список в качестве их первого аргумента, почему те методы не являются просто частью интерфейса List?
Моя интуиция: учитывая Объект списка, тот объект сам должен "знать", как выполнить на себе операции те, которые вращаются (), перестановка (), или реверс (). Но вместо этого, как программист Java, я должен рассмотреть обоих методы в интерфейсе List, а также статические методы "там" в классе Наборов, чтобы гарантировать, что я использую каноническое решение.
Почему некоторые методы были помещены как статические автономные методы в классе Наборов, вместо того, чтобы быть добавленными к интерфейсу List (и по-видимому таким образом реализованными некоторым существующим или потенциальным базовым классом)?
Я пытаюсь лучше понять проектные решения позади платформы наборов Java.
Разве существует ли некоторый востребованный принцип разработки OO здесь, что я пропускаю? Или это различие было сделано просто для некоторых практичных, причина производительности?
5 ответов
Суть в том, что при наличии подходящих примитивных операций (remove, set и т.д.) куча более высокоуровневых операций (sort, shuffle, binary search) может быть реализована один раз, а не реализовываться каждой отдельной реализацией списка.
По сути, java.util.Collections подобен классу Enumerable в .NET - полон методов общего назначения, которые могут работать с любой коллекцией, так что они могут иметь единую реализацию и избежать дублирования.
Это, безусловно, суждение на каком-то уровне. Я думаю, что главный компромисс, который следует учитывать, заключается в следующем: когда вы добавляете метод к интерфейсу, каждый разработчик этого интерфейса должен писать код для его реализации.
Если семантика этого метода такова, что разные реализации интерфейса лучше всего реализуют эту семантику по-разному, то лучше поместить ее в интерфейс. (Конечно, если семантика просто не может быть определена в терминах других методов в интерфейсе, тогда она должна быть ее собственным методом в интерфейсе.)
С другой стороны, если семантика такова, что они могут быть определены в терминах других методов в интерфейсе, и разработчики интерфейса будут просто стремиться писать один и тот же код снова и снова, тогда лучше создать служебный метод, который принимает экземпляр интерфейса как аргумент.
Рациональные методы интерфейса List
- Интерфейс List является очень важной частью среды выполнения Java и уже немного обременительной для полной реализации всех членов при развертывании вашего собственного List реализации. Таким образом, добавление дополнительных методов, не связанных напрямую с определением списка, является немного лишним. Если вам нужны эти методы в реализации List, почему бы не создать подкласс интерфейса, а затем потребовать их?
- Если вы собираетесь прийти, скажем, в версии 1.3 и добавить функциональность в интерфейс List, добавив новые служебные методы, вы сломаете все предыдущие разработчики интерфейса.
- С точки зрения предметно-ориентированного дизайна служебные методы в Коллекциях не являются частью обычного домена списка.
- Что касается принципов объектно-ориентированного проектирования, я думаю, было бы важно провести различие между объектно-ориентированным дизайном приложения и объектно-ориентированным дизайном среды исполнения языка.
Авторы Java могут делать вещи совсем по-другому теперь, когда они задним числом и перспективой многолетнего использования API. Тем не менее, интерфейс C # IList очень похож на интерфейс Java, и авторы C # имели такую перспективу.
Это вспомогательные методы, а не основная функциональность List. Интерфейс List просто раздулся бы, если бы вы добавили все возможные операции, которые можно выполнить над List. А операциям в Collections не нужно знать о внутреннем устройстве List, они работают с общедоступным интерфейсом и могут спокойно жить во внешнем классе.
Здесь есть два объяснения:
Исторический: класс Collections был создан после интерфейса List. Дизайнеры решили сохранить обратную совместимость уже существующего интерфейса. В противном случае многим разработчикам пришлось бы изменить свой код.
Логика: методы, о которых вы говорите, не требуют внутренних знаний о реализации List и могут быть реализованы над ЛЮБОЙ коллекцией, реализующей его.