Информация об изменениях

Сообщение Re[9]: Мнение: объектно-ориентированное программирование — к от 30.09.2019 8:09

Изменено 30.09.2019 11:59 Pauel

Re[9]: Мнение: объектно-ориентированное программирование — к
Здравствуйте, artelk, Вы писали:

A>>>Имхо, было бы полезно, если IList наследовался от IReadOnlyList. Это было бы уточнение типа или расширение модуля?


I>>Разумеется расширение, потому как был Readonly, а стал read-write.

I>>Сам подумай — некий класс ждет, что его данные не могут меняться. Но у тебя то на самом деле IList, то есть, можно модифицировать контейнер, — опаньки, взял, отредактировал, и всё сломал.
I>>Нарушается принцип замещения Лисков.

A>Неверно. IReadOnlyList не про иммутабельность. Класс List, например, реализует этот интерфейс, хотя его в иммутабельности трудно заподозрить.


Значит это нарушение ОО контракта, похоже исторически сложилось что IReadOnlyList никакой не read-only. Массив — да, List — нет.

Тогда такой пример — IImmutableList, который гарантирует неизменность. Всё иммутабельно и тд. А теперь наследуем этот интерфейс, скажем, IOptimized и вставляем туда методы FastRemove, FastAdd и тд, которые будут удалять по месту.

Вроде ж всё хорошо — раз мы наследуем только интерфейс, то никаких подлянок ожидать не стоит. Гы-гы. Проверяем — передаем консумеру экземпляр IOptimized, он благополучно принимает и используем в своих целях. А мы тем временем модифицируем этот же инстанс.

Итого — откуда грабли? Мы ж только интерфейс наследуем...
Re[9]: Мнение: объектно-ориентированное программирование — к
Здравствуйте, artelk, Вы писали:

A>>>Имхо, было бы полезно, если IList наследовался от IReadOnlyList. Это было бы уточнение типа или расширение модуля?


I>>Разумеется расширение, потому как был Readonly, а стал read-write.

I>>Сам подумай — некий класс ждет, что его данные не могут меняться. Но у тебя то на самом деле IList, то есть, можно модифицировать контейнер, — опаньки, взял, отредактировал, и всё сломал.
I>>Нарушается принцип замещения Лисков.

A>Неверно. IReadOnlyList не про иммутабельность. Класс List, например, реализует этот интерфейс, хотя его в иммутабельности трудно заподозрить.


Значит это нарушение ОО контракта, похоже исторически сложилось что IReadOnlyList никакой не read-only. Массив — да, List — нет.

Тогда такой пример — IImmutableList, который гарантирует неизменность. Всё иммутабельно и тд. А теперь наследуем этот интерфейс, скажем, IOptimizedList и вставляем туда методы FastRemove, FastAdd и тд, которые будут удалять по месту.

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

Итого — откуда грабли? Мы ж только интерфейс наследуем...