Нарушает ли Collections.unmodifiableMap (и другие) принципы SOLID?

Question

Недавно я читал Java Concurrency in Practice и впервые познакомился с методом Collections.unmodifiableMap(...). Метод создает доступную только для чтения оболочку вокруг существующего Map, и любые попытки изменить возвращенный Map приведут (согласно Javadocs) к выдаче UnsupportedOperationException. Подобные методы существуют и для других классов коллекций.

Это сильно меня обеспокоило, поскольку unmodifiableMap() по-прежнему возвращает Map, но не поддерживает все соответствующие методы. Тот факт, что он также генерирует исключения для операций записи, означает, что он не может заменить «правильный» Map в большинстве приложений.

Я студент и еще не уверен в своей способности распознавать дизайн fl aws , но разве это не нарушение принципов Interface segregation и Liskov substitution соответственно?

Answer 1

В документах интерфейса Map реализации могут решить не поддерживать все его методы, что заставляет Collections.unmodifiableMap возвращать реализацию, удовлетворяющую контракту интерфейса.

Хотя для интерфейса необычно реализовывать свои методы "необязательный" в этом смысле, это компромисс дизайна, который отлично работает на практике. Большинство коллекций должны быть записаны только один раз, а затем считаны снова и снова, поэтому код, изменяющий карту, обычно является кодом, который ее создал и знает, что она изменяема.

Answer 2

Что касается ISP, Боб Мартин, вероятно, посчитал бы Collections.unmodifiableMap() нарушением в том же духе, что и его пример класса стека . Он предоставляет клиентам интерфейс, который им не нужен и фактически не может использовать.

Как уже упоминалось, LSP удовлетворяется документацией по интерфейсу.