Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Например в метод add суем логику обнуления контейнера.

НС>Кто и зачем сует в метод add логику обнуления контейнера?

Вот бы узнать Я встречал такой код. Итого — как тут интерфейсы помогли?
Как будешь вызывать метод add? Будешь предполагать следование описанию, или подстраховыватся типа "если после добавления длина изменилась непойми как..."

НС>>>У любой технологии есть свои недостатки. Вывод то какой? Не использовать ООП?
I>> наоборот. Если ты понаимплементил интерфейсов это по факту отказ от ооп.

НС>Нет.

Это нарушение всех принципиов вместе взятых, а раз так, то это отказ от ооп.

I>>Непонятно, что ты имеешь ввиду.

НС>Я тут рядом ссылочку дал. Там поподробнее.

С глубокой иерархией интерфейсов все ровно так же. Например, если в иерархии, построеной на иммутабельный принципах, ты решил сделать базовый класс мутабельным, появляются ровно те же проблемы. То есть, ломается всё, что имеет хоть какую то реализацию или же использование.
yo-yo, который упоминается, точно так же имеет место с запутаной иерархией интерфейсов.

I>>- вот ты видишь, что интерфейс иммутабельный и в доке прямо сказано.

НС>Нет, не вижу. Нет такого свойства у интерфейса, оно им ортогонально.

У интерфейса вообще — нету. А вот смысл конкретной абстрации вполне себе может быть в иммутабельности. Например, иммутабельные структуры данных — списки например.
Как будешь использовать такой список, будешь полагаться на свой же дизайн, или будешь подозревать наследников во всех грехах?

НС>Скакать начал ты, притянув за уши иммутабельность. Я же который раз уже пишу очевидное — абсолютных гарантий ни одна конструкция языка не дает и дать не может.

Именно — не может. А раз не язык даёт гарантии, то кто их предоставит?
Кто же даст гарантию, что иммутабельный по дизайну список не имеет мутабельных операций?

I>>Так покажи этот выбор, как ты обеспечишь ту самую гарантию.
НС>Ты пытаешься лишить меня выбора, зачем то навязывая мне потребности в гарантиях иммутабельности.

Это просто пример. Любое свойство так же хорошо для иллюстрации, как и иммутабельность.
Можем взять еще проще — как ты обеспечишь гарантии, что add добавляет в конец списка свой параметр и вытекающие свойства — длина увеличивается на единицу и тд.

И снова тот же вопрос — когда ты вызываешь этот метод add, ожидаешь ли ты, что некто возьмет да и сделает "кастомную реализацию", а именно — очистку списка внутре этого add.
Ну то есть, пишешь ли логику вида "если после добавления список превратился в непойми что...". Самое главное — почему.

I>>Как и везде — компилятор, дизайн, тесты и тд.
НС>И каким образом компилятор назначил иммутабельность внятной, а контроль на null — нет? Можешь пояснить?

Элементарно — компилятор, например, может вычислить изменение свойства. Это ведь его работа, вычислять констреинты.
Если у тебя есть такой компилер, пожалуйста, пользуйся.

I>>Тогда показывай пример, если тебе есть чего сказать.
НС>Чайники Рассела полетели? Это ты давай доказывай, что subtype проблему решит.

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

Кстати говоря, по твоей же ссылке в качестве решения этих же проблем указыается этот самый subtype. Похоже, ты нечитатель, лепишь ссылки не глядя.