Нарушают ли методы Collections.unmodifiableXXX LSP?

LSP говорит, что каждый подкласс должен подчиняться тем же контрактам, что и суперкласс. Так или иначе это относится к Collections.unmodifiableXXX(), поэтому зависит от того, как читается этот контракт.

Объекты, возвращаемые Collections.unmodifiableXXX(), вызывают исключение, если кто-то пытается вызвать для них какой-либо модифицирующий метод. Например, если вызывается add(), будет выброшено UnsupportedOperationException.

Что такое генеральный контракт add()? Согласно документации API это:

Гарантирует, что эта коллекция содержит указанный элемент (дополнительная операция). Возвращает true, если эта коллекция изменилась в результате вызова. (Возвращает false, если эта коллекция не допускает дубликатов и уже содержит указанный элемент.)

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

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

Это явно позволяет реализации иметь код, который не добавляет аргумент add в коллекцию, но приводит к исключению. Конечно, это включает в себя обязательство клиента коллекции учитывать эту (юридическую) возможность.

Таким образом, поведенческий подтип (или LSP) все еще выполняется. Но это показывает, что если кто-то планирует иметь различное поведение в подклассах, это также должно быть предусмотрено в спецификации класса верхнего уровня.

Кстати, хороший вопрос.

Да, я считаю, что вы правильно поняли. По существу, чтобы выполнить LSP, вы должны иметь возможность делать с подтипом все, что вы могли бы делать с супертипом. Именно поэтому проблема эллипса/окружности возникает в LSP. Если у Ellipse есть метод setEccentricity, а Circle является подклассом Ellipse, а объекты должны быть изменяемыми, то Circle никак не может реализовать метод setEccentricity. Таким образом, с Эллипсом можно сделать что-то, чего нельзя сделать с Окружностью, так что LSP нарушается. Точно так же есть кое-что, что вы можете сделать с обычным List, чего нельзя сделать с обернутым Collections.unmodifiableList, так что это нарушение LSP.

Проблема в том, что здесь есть что-то, что нам нужно (неизменяемый, немодифицируемый, доступный только для чтения список), что не захвачено системой типов. В C# вы можете использовать IEnumerable, который отражает идею последовательности, которую вы можете повторять и читать, но не записывать. Но в Java есть только List, который часто используется для изменяемого списка, но который мы иногда хотели бы использовать для неизменяемого списка.

Некоторые могут сказать, что Circle может реализовать setEccentricity и просто выдать исключение, и аналогичным образом неизменяемый список (или неизменяемый список из Guava) выдает исключение, когда вы пытаетесь его изменить. Но на самом деле это не означает, что это является списком с точки зрения LSP. Во-первых, это как минимум нарушает принцип наименьшей неожиданности. Если вызывающий объект получает неожиданное исключение при попытке добавить элемент в список, это весьма удивительно. И если вызывающему коду необходимо предпринять шаги, чтобы отличить список, который он может изменить, от списка, который он не может (или форму, эксцентриситет которой он может установить, и одну, которую он не может), то одно на самом деле не заменяет другое. .

Было бы лучше, если бы в системе типов Java был тип для последовательности или коллекции, который допускал бы только итерацию, а другой тип допускал бы модификацию. Возможно, для этого можно использовать Iterable, но я подозреваю, что в нем отсутствуют некоторые функции (например, size()), которые действительно нужны. К сожалению, я думаю, что это ограничение текущего API коллекций Java.

Несколько человек отметили, что документация для Collection позволяет реализации генерировать исключение из метода add. Я предполагаю, что это означает, что Список, который не может быть изменен, подчиняется букве закона, когда речь идет о контракте для add, но я думаю, что нужно изучить свой код и посмотреть, сколько мест есть, которые защищают вызовы мутирующих методов. списка (add, addAll, remove, clear) с блоками try/catch, прежде чем утверждать, что LSP не нарушен. Возможно, это не так, но это означает, что весь код, вызывающий List.add в списке, полученном в качестве параметра, неисправен.

Это, конечно, о многом бы сказало.

(Аналогичные аргументы могут показать, что идея о том, что null является членом каждого типа, также является нарушением принципа подстановки Лискова.)

Я знаю, что есть и другие способы решения проблемы Ellipse/Circle, например сделать их неизменяемыми или удалить метод setEccentricity. Я говорю здесь только о самом распространенном случае, в качестве аналогии.

Я не считаю это нарушением, потому что в контракте (то есть в интерфейсе List) сказано, что операции мутации необязательны.

Я думаю, вы не смешиваете вещи здесь.
Из LSP:

Понятие Лискова о поведенческом подтипе определяет понятие заменяемости изменяемых объектов; то есть, если S является подтипом T, то объекты типа T в программе могут быть заменены объектами типа S без изменения каких-либо желаемых свойств этой программы (например, правильности).

LSP относится к подклассам.

Список — это интерфейс, а не суперкласс. Он определяет список методов, предоставляемых классом. Но отношения не связаны, как с родительским классом. Тот факт, что классы A и B реализуют один и тот же интерфейс, ничего не гарантирует в отношении поведения этих классов. Одна реализация может всегда возвращать true, а другая выдавать исключение или всегда возвращать false или что-то еще, но обе они придерживаются интерфейса, поскольку реализуют методы интерфейса, поэтому вызывающая сторона может вызывать метод для объекта.