Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, artelk, Вы писали:

A>>>>Имхо, было бы полезно, если IList наследовался от IReadOnlyList. Это было бы уточнение типа или расширение модуля?
I>>>Разумеется расширение, потому как был Readonly, а стал read-write.
I>>>Сам подумай — некий класс ждет, что его данные не могут меняться. Но у тебя то на самом деле IList, то есть, можно модифицировать контейнер, — опаньки, взял, отредактировал, и всё сломал.
I>>>Нарушается принцип замещения Лисков.
A>>Неверно. IReadOnlyList не про иммутабельность. Класс List, например, реализует этот интерфейс, хотя его в иммутабельности трудно заподозрить.
I>Значит это нарушение ОО контракта, похоже исторически сложилось что IReadOnlyList никакой не read-only. Массив — да, List — нет.

Название интерфейса вводит в заблуждение, согласен. Но в контракте у него прописано:

Represents a read-only collection of elements that can be accessed by index.
The IReadOnlyList<T> represents a list in which the number and order of list elements is read-only. The content of list elements is not guaranteed to be read-only.

Допустим он назывался бы IListReadOnlyAccess, IReadableList или IListReader.
Мой вопрос остается в силе.

I>Тогда такой пример — IImmutableList, который гарантирует неизменность. Всё иммутабельно и тд. А теперь наследуем этот интерфейс, скажем, IOptimizedList и вставляем туда методы FastRemove, FastAdd и тд, которые будут удалять по месту.
I>Вроде ж всё хорошо — раз мы наследуем только интерфейс, то никаких подлянок ожидать не стоит. Гы-гы. Проверяем — передаем консумеру IImmutableList экземпляр IOptimizedList, он благополучно принимает и используем в своих целях. А мы тем временем модифицируем этот же инстанс.
I>Итого — откуда грабли? Мы ж только интерфейс наследуем...
Это все очевидно и к вопросу не относится.