Здравствуйте, samius, Вы писали:
S>Однако, моделирование столкновений частиц с помощью ООП (да и ФП, что говорить) — то еще садо-мазо и оверхед. Такие вещи делают на Си/Фортранах, объекты там обычно избыточны.
В ООП не нужно создавать классы для всего подряд, в данном случае частиц и не плодить экземпляры. Сервис который обрабатывает данные — вполне себе рабочий вариант, который вписывается в ООП. Сам сервис может быть стейтлесс и унутре может хоть дифуры считать используюя ФП, это всё будет ООП.
Re[9]: Мнение: объектно-ориентированное программирование — к
Здравствуйте, samius, Вы писали:
S>Здесь дело не в функциональном подходе. Просто увидел упоминание рендеринга, а я с ним имел дело давным-давно. Безотносительно подхода речь лишь о здравом смысле. Если нужно нарисовать 1000000 елок или пуль, то при засовывании координаты внутрь объекта потребуется создать (и удалить потом) 1000000 объектов, которые будут отличаться лишь координатой, т.е. одним атрибутом. В ситуации, когда координату суют не в объект, то объект нужен лишь один.
Кроме координат есть еще кучка свойств, как правило. Делать это честным объектом или не делать, непринципиально. Все равно надо создать 1000000 единиц данных. Если делать это объектом, вообще ничего не изменится, ни с т.з. перформанса, ни с т.з. потребления памяти.
S>Если опустить оптимизации (типа предварительной проверки пересечения траекторий или сегментации сцены), то в ФП нет никакой проблемы построить коллекцию вычисленных координат для данного кадра и сделать проверку в рамках полученной коллекции координат.
Самое интересное в этих самых оптимизация, цель — выжать вообще всё, что можно.
S>Это зависит от задачи прежде всего. Для расчета тех же коллизий можно же не вписывать координату в объект, а наоборот, к вычисленной координате добавить ссылку на объект, либо находить объект по индексу координаты в массиве ссылок. Так процесс проверки координат на коллизии даст меньше промахов кэша при проверке всех со всеми (с большим кол-вом объектов), чем если в кэше будут большие объекты с маленькой координатой, которую надо проверить.
Что значит "большой объект" ? Если много данных, то их и так придется создавать в большом количестве, а от добавления методов сам объект не станет больше.
Re[6]: Мнение: объектно-ориентированное программирование — катастрофа на триллио
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, artelk, Вы писали:
A>>ООП родился как аналогия со ментальной моделью биологических организмов, состоящих из клеток. Поведение организма сложно, а клетки, из которых он состроит, якобы просты. I>Это ты чуть позже опровергнешь.
Что именно?
A>>Клетки общаются сигналами без передачи вещества. Аналогом этому был data hiding с "посылкой сообщений" вместо передачи данных (неясно только почему параметры у методов при этом не запретили). I>Да потому и не запретили, потому что сообщение это передача данных.
Значит мы на первом же шаге отходим от своей же аналогии, окей.
A>>Еще была фантазия о том, что нам легче понимать ООП код, так как мы якобы сами мыслим мир как совокупность объектов с поведением. I>Именно. Один из подходов к проектированию в ООП, это представить, как бы эту задачу решала группа людей. Распределить обязанности, что бы не было конфликтов, выделить роли, выявить сущности, наладить взаимодействие.
Трудно придумать когда это может понадобится, кроме как собственно при моделировании поведения людей. Даже при моделировании ролей в бизнесс процессах нет смысла отвлекаться на то, что без компьютеров их бы выполняли люди.
A>>Не знаю как у других, но для меня объектами с собственным поведением мыслятся в основном только люди (ну и животные отчасти) и имено они являются самыми сложными штуками. I>И это тоже сейчас опровергнешь.
Тут "в основном" всмысле "чаще всего", "бОльшую часть времени".
A>>Все остальное это пассивные предметы, состояние которых я могу менять: надавил на дверь — она открылась; нажал на педаль газа автомобиля — поехали. A>>Автомобиль как нечто имеющее собственное поведение представлялся только в начале обучения езды на нем. I>Вот и опровержение.
Не понимаю, что я опровергнул.
Объектом с собственным поведением воспринимается объект, поведение которого сложно и не предсказуемо.
Довольно странно при разработке приложения следовать этой метафоре и ожидать, что в результате поведение этого приложения не будет тоже сложным и не предсказуемым.
A>>Далее пришли другие теоретики и переопредилили ООП, подсунув трех китов в качестве основной идеи. Основным преимуществом ООП обозначили якобы повышенную способность кода к повторному использованию, т.к. у нас есть наследование (под которым понималось наследование реализации), а у других нет.
I>Проблема именно в трех китах и неправильном реюзе. Наследование плохо не потому, что реализация наследуется. I>Наследование это 2 вещи I>1. уточнение типа I>2. расширение модуля
I>1 — хорошо, когда это необходимо и разницы нет, есть реализация, или нет. 2 — почти всегда плохо.
I>Более того, наследование итерфейсов никак не ухудшает ОО-ность. Тут ровно те же правила. I>Если начнешь расширять интерфейс как модуль, появляются те же грабли, только в профиль.
Имхо, было бы полезно, если IList наследовался от IReadOnlyList. Это было бы уточнение типа или расширение модуля? I>Если использовать интерфейс как уточнение типа — снова всё в порядке.
Примеров бы.
Джаву в 90х дизайнили очень ОО-нутые люди. Для указания наследования классов они выбрали слово "extends", что как бы намекает.
Не кажется ли тебе, что то, что ты считаешь современным ООП существенно противоположно тому, чем оно было в 90е?
А может то, что ты считаешь современным ООП, вовсе не ООП уже, а само ООП не сильно-то поменялось с 90х?
https://en.wikipedia.org/wiki/Object-oriented_programming
Думаю, что после полувека активного продвижения ООП в массы, в википедии, наверно, отражены наиболее распространенное мнение относительно того, в чем его суть.
А поскольку ООП это не то, что мы исследуем, а то, что постулируем (см. выше), то наиболее распространенное мнение и выражает содержание.
И "современное ООП" должно логически из него выводится и нисколько ему не противоречить.
Есть возражения?
На всякий случай отмечу, что фразы вида "ООП позволяет повысить повторную используемость и поддерживаемость" не являются его (ООП) определением.
Так что если у кого-то, при написании кода на языке с классами, интерфейсами и т.п., пришла некая идея как повысить эти два полезных свойства кода, совсем не обязательно, что это следствие "углубления его понимания сущности ООП" и т.п. Вполне возможно, что эта идея вообще противоречит ООП.
A>>Практика показала, что она отличается от теории и стало понятно, что повторная испольуемось достигается за как раз счет полиморфизма, а не наследования. Появились Coding to the interface, GoF и т.п. I>Повторное использование это гораздо шире, чем наследование или полиморфизм или инкапсуляция или всё вместе.
Да, Math.Abs можно использовать много где и никакого полиморфизма при этом не требуется. Но Math.Abs он и в функциональном и в структорном программировании такой же.
А мы тут обсуждаем что именно есть такого в ООП для обеспечения повторного использования.
I>Симуловскиая модель трех китов давно уже неадекватная. Но ООП не сводится к симуловской модели трех китов.
I>>>Софтварные продукты постоянно растут в сложности, а потому арсенал пополняется самыми разными приемами. A>>Можно развернуто, с примерами?
I>Абстракция давно уже четвертый кит.
Ага, с какого-то момента стало модно к трем китам добавлять еще эту селедку.
Только зачем отдельным пунктом добавлять то, что подразумевается по умолчанию при обсуждении процесса разработки приложений безотносительно используемой парадигмы?
I>Взаимодействие — еще один. I>Поведение — еще один.
Все эти слова, абстракция, взаимодействие, поведение, часто употреблялись в литературе 90х при описании того, что такое ООП; т.е. ничего нового.
Или у этих слов внезапно тоже появился новый, современный смысл?
I>Вместо "данные + методы" используем подход "сервис который занят обработкой данных", типа "экскаватор копает землю" @ Sinclair
Да, но эта модель ближе к функциональному программированию, чем к ООП 90х (с продающими себя продуктами и аккаунтами, переводящими средства с себя на другие аккаунты и т.п.)
Особенно будет заметно, если функционал расчета траектории ковша экскаватора вынести в отдельную чистую функцию.
I>>>А местные ОО-хейтеры до сих пор три кита ищут. A>>Ок, три кита уплыли. Что осталось?
I>А тут надо вспомнить Алана Кея и его принципы. Эта ветвь ислама ООП никогда не переставала быть актуальной.
А не он ли сам утверждал, что все его неправильно поняли и он имел ввиду совсем другое, не имеющее ничего общего с тем, что получило распространение как ООП?
Тут три варианта что делать:
1. Поменять название у парадигмы, которая всеми ошибочно называется ООП, на какое-то другое, так как это название Алан Кей придумал для другого.
2. Решить, что этимология термина не всегда отражает его смысл и оставить название ООП этой парадигме. А для идей Алана Кея придумать новое название Message Oriented Programming.
3. Научиться вовремя отключать мозг, не замечать ничего странного.
Первый вериант невозможен по историческим причинам. Второй вариант не реализуется по причине того, что пока в массах побеждает третий.
I>Самое главное в ООП — это обмен сообщениями, абстрагирование, иерархическая композиция объектов, взаимодействие, моделирование поведения.
"Обмен сообщениями" требует уточнения. Без уточнения даже каждая строчка ассемблерного кода может интерпретироваться как некая "посылка сообщения от одного объекта другому".
Сообщения должны слаться асинхронно по принципу fire and forget?
Или это про то, что можно вызвать у объекта неизвестный на этапе написания программы метод, а объект в рантайме как-то разберется как его выполнять (т.е. сугубая динамика)?
Здравствуйте, artelk, Вы писали:
A>>>ООП родился как аналогия со ментальной моделью биологических организмов, состоящих из клеток. Поведение организма сложно, а клетки, из которых он состроит, якобы просты. I>>Это ты чуть позже опровергнешь. A>Что именно?
Твое высказывание.
A>>>Клетки общаются сигналами без передачи вещества. Аналогом этому был data hiding с "посылкой сообщений" вместо передачи данных (неясно только почему параметры у методов при этом не запретили). I>>Да потому и не запретили, потому что сообщение это передача данных. A>Значит мы на первом же шаге отходим от своей же аналогии, окей.
Ты с потолка взял некую "ментальной моделью биологических организмов". На самом деле ментальная модель ровно одна — человеческого мышления, т.е. основаная на накопленном опыте методы, подходы, стратегии, тактики, идеи направляющие деятельность человека
I>>Именно. Один из подходов к проектированию в ООП, это представить, как бы эту задачу решала группа людей. Распределить обязанности, что бы не было конфликтов, выделить роли, выявить сущности, наладить взаимодействие. A>Трудно придумать когда это может понадобится, кроме как собственно при моделировании поведения людей. Даже при моделировании ролей в бизнесс процессах нет смысла отвлекаться на то, что без компьютеров их бы выполняли люди.
Эта модель используется вообще везде, гораздо ширше чем в ООП.Для примера — посимвольное копирование строки.
Нам нужно три человека — управляющий, человек для выборки, человек для укладки.
Управляющий сообщает откуда выбирать, и куда укладывать, ведет счет и дает отмашку начала-конца работ.
Один человек занимается выборкой символов из строки, по символу за раз и передает укладчику.
Укладчик принимает символы и укладывает , по символу за раз.
Например, таким методом идет погрузка-разгрузка кирпича. Все алгоритмы, до единого, укладываются в эту модель. ООП распространяет эту модель на структурирование любого масштаба.
A>>>Все остальное это пассивные предметы, состояние которых я могу менять: надавил на дверь — она открылась; нажал на педаль газа автомобиля — поехали. A>>>Автомобиль как нечто имеющее собственное поведение представлялся только в начале обучения езды на нем. I>>Вот и опровержение. A>Не понимаю, что я опровергнул.
Ты придумал некую "ментальную модель биологических организмов", а сам приводишь примеры совсем другого рода.
A>Объектом с собственным поведением воспринимается объект, поведение которого сложно и не предсказуемо. A>Довольно странно при разработке приложения следовать этой метафоре и ожидать, что в результате поведение этого приложения не будет тоже сложным и не предсказуемым.
Поведение это любая зависимость от предыстории. Например — счетчик. Это именно поведение. Простое и предсказуемое.
I>>Более того, наследование итерфейсов никак не ухудшает ОО-ность. Тут ровно те же правила. I>>Если начнешь расширять интерфейс как модуль, появляются те же грабли, только в профиль. A>Имхо, было бы полезно, если IList наследовался от IReadOnlyList. Это было бы уточнение типа или расширение модуля?
Разумеется расширение, потому как был Readonly, а стал read-write.
Сам подумай — некий класс ждет, что его данные не могут меняться. Но у тебя то на самом деле IList, то есть, можно модифицировать контейнер, — опаньки, взял, отредактировал, и всё сломал.
Нарушается принцип замещения Лисков.
I>>Если использовать интерфейс как уточнение типа — снова всё в порядке. A>Примеров бы.
Так уже. IList и IReadonlyList это независимые наследники некоего базового
A>Джаву в 90х дизайнили очень ОО-нутые люди. Для указания наследования классов они выбрали слово "extends", что как бы намекает. A>Не кажется ли тебе, что то, что ты считаешь современным ООП существенно противоположно тому, чем оно было в 90е?
В джаве как раз коллекции тех времен упоротые донельзя. Хочешь посмотреть внятные коллекции — смотри дотнет. Например благодаря фокусу выше в коллекцию котов можно добавить собаку.
A>А может то, что ты считаешь современным ООП, вовсе не ООП уже, а само ООП не сильно-то поменялось с 90х?
Наоборот. 90х ООП еще про свободные методы мало кто знал, хотя уже была известа концепция. Замещение Лисков — мало кто догадывался.
A>https://en.wikipedia.org/wiki/Object-oriented_programming A>Думаю, что после полувека активного продвижения ООП в массы, в википедии, наверно, отражены наиболее распространенное мнение относительно того, в чем его суть.
Ого, давно Википедия стала авторитетом в Computer Sciense ?
A>А поскольку ООП это не то, что мы исследуем, а то, что постулируем (см. выше), то наиболее распространенное мнение и выражает содержание.
1 Это аргмент про "большинство". На самом деле большинство не в курсе даже про принцип Лисков, а эта вещь лежит в основе такой мат модели, как Абстрактные типы данных.
Внезапно, ООП вовсю использует эту модель. И по твоему, раз большинство не знает, то этого и нет. Гы-гы
2 Замещение Лисков — эта модель растет из нашего опыта, смотри всякие виды соединений, передач — шиповое, например, или зубчатая передача и тд. Да даже дверь обычная и то подчиняется этому закону.
Из п.1 и п.2 ясно, что ООП не постулируется, ООП это то, что мы нашли в мышлении человека и начинаем применять осознанно.
A>И "современное ООП" должно логически из него выводится и нисколько ему не противоречить. A>Есть возражения?
Это софистика. Ты чего то постулируешь, притягиваешь аргументы про википедию, какие то аналогии и делаешь из этого какие то выводы
A>Да, Math.Abs можно использовать много где и никакого полиморфизма при этом не требуется. Но Math.Abs он и в функциональном и в структорном программировании такой же. A>А мы тут обсуждаем что именно есть такого в ООП для обеспечения повторного использования.
Как ты сам сказал, повторное использование это побочный продукт. Основное в ООП это управление сложностью.
I>>Абстракция давно уже четвертый кит. A>Ага, с какого-то момента стало модно к трем китам добавлять еще эту селедку. A>Только зачем отдельным пунктом добавлять то, что подразумевается по умолчанию при обсуждении процесса разработки приложений безотносительно используемой парадигмы?
Это не селедка, это самое главное. Именно за счет абстракции мы и управляем сложностью. Это нужно в силу ограниченого окна внимания у человека.
А вот всё остальное можно просто выбросить, т.к. это малая часть строительных кирпичей. Малая, потому что например наряду с наследованием, т.е. отношение тип-подтип, есть и композиция, делегирование, агрегирование и разные другие отношения.
I>>Взаимодействие — еще один. I>>Поведение — еще один. A>Все эти слова, абстракция, взаимодействие, поведение, часто употреблялись в литературе 90х при описании того, что такое ООП; т.е. ничего нового. A>Или у этих слов внезапно тоже появился новый, современный смысл?
Употреблялись, но почему то забывали указать, что это и есть самое главное. А вот инкапсулируешь ли ты, наследуешь или композируешь, дело десятое.
I>>Вместо "данные + методы" используем подход "сервис который занят обработкой данных", типа "экскаватор копает землю" @ Sinclair A>Да, но эта модель ближе к функциональному программированию, чем к ООП 90х (с продающими себя продуктами и аккаунтами, переводящими средства с себя на другие аккаунты и т.п.)
Нисколько. Эти вещи были с начала времен. Когда то роль экскаватора выполнял человек, потом группа людей, потом специальные машины с ручными приводом, потом это дело совершенствовалось и дошло до экскаватора. По этому же принципу работает вся хардвара. То есть, это все по своей сути есть чистый сайд эффект.
Функционалисты нашли свой способ моделирования решения, через лямбда-счисление. Императивные товарищи используют более традиционную модель.
А вот ООП придает структура. В лямда-счислении нет никаких сервисов. Упаковываем функции определенным способом, что бы абстрагироваться от деталей — упс, изобретаем ООП.
И в языках типа Окамл давно это поняли.
A>Особенно будет заметно, если функционал расчета траектории ковша экскаватора вынести в отдельную чистую функцию.
Если ты выделил сервис, то это уже ООП. А чисто там внури, или мутабельно — дело десятое.
Все языки устроены послойно. Наверху — парадигма для структурирования, внизу — для вычислений.
ООП само по себе ничего никогда не вычисляло, этим занимался нижний уровень — императивное, функциональное, логическое программирование и какие угодно вычислительные модели.
Функционалисты используя чисто функциональные вещи сэмулировали ООП. Что изменилось то? Как был сервис, так и остался сервис == экскаватор
I>>А тут надо вспомнить Алана Кея и его принципы. Эта ветвь ислама ООП никогда не переставала быть актуальной. A>А не он ли сам утверждал, что все его неправильно поняли и он имел ввиду совсем другое, не имеющее ничего общего с тем, что получило распространение как ООП?
Осталось заметить, что динамические языки, а это и есть та самая ветка, доминируют. И тут симуловским китам тут делать нечего.
A>Сообщения должны слаться асинхронно по принципу fire and forget?
А это не имеет значения. Меняется только протокол взаимодействия, а ООП может работать и так, и так. Я же говорю — ООП это структурирующая парадигма, ей без разницы, что структурировать — сихнронный, асинхронный, функциональный, императивный, логический, реактивный, функционально-реактивный код.
A>Или это про то, что можно вызвать у объекта неизвестный на этапе написания программы метод, а объект в рантайме как-то разберется как его выполнять (т.е. сугубая динамика)?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, artelk, Вы писали:
A>>Имхо, было бы полезно, если IList наследовался от IReadOnlyList. Это было бы уточнение типа или расширение модуля?
I>Разумеется расширение, потому как был Readonly, а стал read-write. I>Сам подумай — некий класс ждет, что его данные не могут меняться. Но у тебя то на самом деле IList, то есть, можно модифицировать контейнер, — опаньки, взял, отредактировал, и всё сломал. I>Нарушается принцип замещения Лисков.
Неверно. IReadOnlyList не про иммутабельность. Класс List, например, реализует этот интерфейс, хотя его в иммутабельности трудно заподозрить.
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, он благополучно принимает и используем в своих целях. А мы тем временем модифицируем этот же инстанс.
Итого — откуда грабли? Мы ж только интерфейс наследуем...
Здравствуйте, meadow_meal, Вы писали:
BFE>>Рассмотрим две программы которые спрашивают у пользователя два числа и выдают результатом их сумму. Одна программа написана на функциональном языке, а другая на императивном. Принципиальная разница между ними следующая: программа написанная на функциональном языке не помнит своего предыдущего состояния и на два заданных числа всегда выдаёт их сумму, а программа написанная на императивном языке может помнить что было раньше и выдавать сумму всех когда либо поданных на ввод чисел, а не только двух последних.
_>Почему? Вот типичная функциональная программа (псевдокод)
_>main(State) = main(step(State)) _>где step — шаг алгоритма, который принимает на вход текущее состояние программы, выполняет полезную работу (например, читает числа и выводит сумму), и возвращает новое состояние, в котором без проблем можно передавать результаты всех предыдущих вычислений.
И тогда State — это объект и программа написана на императивном языке.
Чтобы рассматривать эту программу как функциональную нужно полагать, что State — это функция ввода-вывода, которая связывает (через преобразования) входные параметры с выходными.
И каждый день — без права на ошибку...
Re[10]: Мнение: объектно-ориентированное программирование — к
Здравствуйте, 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>Итого — откуда грабли? Мы ж только интерфейс наследуем...
Это все очевидно и к вопросу не относится.
Re[11]: Мнение: объектно-ориентированное программирование — к
Здравствуйте, artelk, Вы писали:
A>Название интерфейса вводит в заблуждение, согласен. Но в контракте у него прописано: A>
A>Represents a read-only collection of elements that can be accessed by index.
A>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.
Я уже ответил, что этот пример плохой для рассмотрения и ты сам показал почему — изначально некорректный контракт. Это именно расширение, т.к. ты декларируешь две прямо противоположные вещи — список ReadOnly но в ём есть операции для модификации
Но в дотнете это не создаст большой проблемы, потому как контракт уже некорректный и используется абы как. Правильно было бы использовать такой IReadonlyList только массивах, и только таких, которые нельзя изменить никоим образом(Freezed или как там). Но в дотнете начался хаос и такую хрень распространили чуть не повсюду. Фактически, таким интерфейсом ограничиваются пермишны. Где надо обойти — запрашиваем IList и тут же модифицируем то, что по идее для чтения.
A>Допустим он назывался бы IListReadOnlyAccess, IReadableList или IListReader.
Я про контракт, он уже кривой шо сабля.
A>Мой вопрос остается в силе.
Я дал подобный ответ на примере IImmutableList — каким образом расширение интерфейса может всё сломать.
I>>Тогда такой пример — IImmutableList, который гарантирует неизменность. Всё иммутабельно и тд. А теперь наследуем этот интерфейс, скажем, IOptimizedList и вставляем туда методы FastRemove, FastAdd и тд, которые будут удалять по месту. I>>Вроде ж всё хорошо — раз мы наследуем только интерфейс, то никаких подлянок ожидать не стоит. Гы-гы. Проверяем — передаем консумеру IImmutableList экземпляр IOptimizedList, он благополучно принимает и используем в своих целях. А мы тем временем модифицируем этот же инстанс. I>>Итого — откуда грабли? Мы ж только интерфейс наследуем... A>Это все очевидно и к вопросу не относится.
Это все тот же вопрос — как наследование интерфейсов может все сломать.
Re[12]: Мнение: объектно-ориентированное программирование — к
Здравствуйте, Ikemefula, Вы писали:
A>>Допустим он назывался бы IListReadOnlyAccess, IReadableList или IListReader. I>Я про контракт, он уже кривой шо сабля.
Нормальный контракт, имя интерфейса просто неоднозначное.
Давай аналогичный пример приведу: IList наследует от IEnumerable.
A>>Мой вопрос остается в силе. I>Я дал подобный ответ на примере IImmutableList — каким образом расширение интерфейса может всё сломать.
Уфф.. давай с другой стороны. Что ты называешь расширением модуля. Когда при наследовании интерфейсов он не расширяется?
Re[13]: Мнение: объектно-ориентированное программирование — к
Здравствуйте, artelk, Вы писали:
I>>Я про контракт, он уже кривой шо сабля. A>Нормальный контракт, имя интерфейса просто неоднозначное. A>Давай аналогичный пример приведу: IList наследует от IEnumerable.
Чем тебя не устраивает пример с IImmutableList ? Вроде все предельно ясно.
Наследование IList от IEnumerable это уточнение, т.к. любой IList, в т.ч. пустой, сохраняет все гарантии доставшиеся в наследство от IEnumerable, а именно — возможность простой итерации.
На самом деле у интерфейса всегда есть семантика. Это не просто какие то названия, это соглашение вида синтаксис->семантика. Проблемы возникают именно из за этой семантики. Если закрыть глаза на семантику, то нет разницы, что от чего наследовать.
Игнорируя семантику можно определить наследник IList где Add удаляет, а не добавляет, и возвращает не позицю, а рандом. А можно ICircle пронаследовать от IRectangle. Никто ведь не запрещает и это не только скомпилируется, но и заработает
A>>>Мой вопрос остается в силе. I>>Я дал подобный ответ на примере IImmutableList — каким образом расширение интерфейса может всё сломать. A>Уфф.. давай с другой стороны. Что ты называешь расширением модуля. Когда при наследовании интерфейсов он не расширяется?
Это не мой термин Уточнение — это подмножество некоторого типа. Например — круги определенного цвета. Расширение — объединение множеств. Например множества кругов и прямогольников.
Скажем, уточнением будет наследник IImmutableList, у которого добавится, скажем, immutable операция "GetDistinctItems"
Расширением будет такой наследник IImmutableList, у которого добавится операция "MakeDistinct" с семантикой изменения по месту.
Re[14]: Мнение: объектно-ориентированное программирование — к
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, artelk, Вы писали:
I>На самом деле у интерфейса всегда есть семантика. Это не просто какие то названия, это соглашение вида синтаксис->семантика. Проблемы возникают именно из за этой семантики. Если закрыть глаза на семантику, то нет разницы, что от чего наследовать.
Да, но семантика IReadOnlyList отличается от предложенного тобой IImmutableList.
A>>Уфф.. давай с другой стороны. Что ты называешь расширением модуля. Когда при наследовании интерфейсов он не расширяется?
I>Это не мой термин Уточнение — это подмножество некоторого типа. Например — круги определенного цвета. Расширение — объединение множеств. Например множества кругов и прямогольников. I>Скажем, уточнением будет наследник IImmutableList, у которого добавится, скажем, immutable операция "GetDistinctItems" I>Расширением будет такой наследник IImmutableList, у которого добавится операция "MakeDistinct" с семантикой изменения по месту.
Так расширение типа или модуля\интерфейса?
Понятно, что если само "расширение интерфейса" определить как "противоположность уточнению типа", то доказательство твоего утверждения становится тавтологичным.
Я же предлагаю придерживаться более интуитивного определения "расширения интерфейса" как просто добавление новых методов.
Тогда получается, что при наследовании интерфейсов обычно (за ислючением экзотики с пустыми интерфейсами-наследниками) происходит расширение интерфейса.
"Хорошо" это когда такое наследование сопровождается сужением\уточнением типа (тут принято вспоминать LSP, контрактное программирование и т.п.)
Re: Мнение: объектно-ориентированное программирование — катастрофа на триллион д
Здравствуйте, кт, Вы писали:
кт>C++ — ужасный [объектно-ориентированный] язык… Ограничение вашего проекта до C означает, что люди не напортачат ни с какой идиотской «объектной моделью». кт>Линус Торвальдс, создатель Linux
кт>Линус Торвальдс широко известен своей открытой критикой C++ и ООП. Одна вещь, в которой он был на 100 % прав — это необходимость ограничения программистов в выборе. На самом деле, чем меньше у программистов выбора, тем более устойчивым становится их код. В приведённой выше цитате Торвальдс настоятельно рекомендует иметь хороший фреймворк, на котором будет основан ваш код.
Походу помидор фуллстек просто не понимает, о чём пишет. Вот уж в C программиста вообще ничего не ограничивает, кроме степени извращённости фантазии.
Re[3]: Мнение: объектно-ориентированное программирование — катастрофа на триллио
Здравствуйте, AlexRK, Вы писали:
ARK>Т.е. речь идет не о "чистом ООП-подходе" а-ля stateful агенты с иммутабельными сообщениями, а о том, что есть в мейнстримовом ООП — ссылки и бесконтрольные изменения всего отовсюду, высокая связность.
Так в современном ООП как раз придуманы паттерны и интерфейсы, чтобы изолировать всё как надо. Автор же пишет, что паттерны нинужно, интерфейсы и полиморфизм нинужно, про слово const вообще походу не слышал.
Re[15]: Мнение: объектно-ориентированное программирование — к
Здравствуйте, artelk, Вы писали:
I>>На самом деле у интерфейса всегда есть семантика. Это не просто какие то названия, это соглашение вида синтаксис->семантика. Проблемы возникают именно из за этой семантики. Если закрыть глаза на семантику, то нет разницы, что от чего наследовать. A>Да, но семантика IReadOnlyList отличается от предложенного тобой IImmutableList.
Вроде же обсудили это. Что еще непонятно?
I>>Скажем, уточнением будет наследник IImmutableList, у которого добавится, скажем, immutable операция "GetDistinctItems" I>>Расширением будет такой наследник IImmutableList, у которого добавится операция "MakeDistinct" с семантикой изменения по месту.
A>Так расширение типа или модуля\интерфейса?
Интерфейса. Здесь никакой разницы с типами нет. Интерфейс привязан к семантике, а потому ведет себя как тип. Интерфейсы используют и вне семантики, это не запрещено, собственно там и огребают проблемы.
A>Понятно, что если само "расширение интерфейса" определить как "противоположность уточнению типа", то доказательство твоего утверждения становится тавтологичным.
Цитирую себя "Уточнение — это подмножество некоторого типа. Например — круги определенного цвета. Расширение — объединение множеств. Например множества кругов и прямогольников."
A>Я же предлагаю придерживаться более интуитивного определения "расширения интерфейса" как просто добавление новых методов.
Это "интуитивное" и является причной проблемы.
A>Тогда получается, что при наследовании интерфейсов обычно (за ислючением экзотики с пустыми интерфейсами-наследниками) происходит расширение интерфейса. A>"Хорошо" это когда такое наследование сопровождается сужением\уточнением типа (тут принято вспоминать LSP, контрактное программирование и т.п.)
Ну да, только что определили интуитивно, и тут же надо учить, как же правильно пользоваться этим интуитивным
Re[17]: Мнение: объектно-ориентированное программирование — катастрофа на трилли
Здравствуйте, Ikemefula, Вы писали:
I>Не совсем понятно, как машине тьюринга смоделирован ввод-вывод. Скорее всего, лента уже включает в себя эти данные для вывода. В таком случае, все хорошо, и там и там работает.
В машине Тьюринга смоделировать ввод вывод очень просто: можно считать, что есть ячейка, в которой данные иногда самопроизвольно меняются, но не чаще, чем, скажем, один раз за 100 операций. Вывод — аналогично. Символ считается выведенным, если его записали в ячейку по определённому адресу.
I>В противном случае надо придумывать мат-модель этого ввода-вывода, каким образом появляются данные неуточненного типа в памяти программы.
Почему неуточнённого? Можно считать, что ввод-вывод производится в рамках алфавита.
И каждый день — без права на ошибку...
Re[19]: Мнение: объектно-ориентированное программирование — катастрофа на трилли
Здравствуйте, Sinclair, Вы писали:
S>>>Так и делаются вещи типа буферов и хранения состояния — конструируется функция, возвращающая функцию, возвращающую функцию и т.п. BFE>>Буфер и вещь типа буфера — это не одно и тоже. S>Буфер с т.з. контракта — это очередь.
Этот контракт предполагает одновременное выполнение чтение и записи?
S>Вот статья, в которой на пальцах показана реализация очереди в ФП. S>https://habr.com/ru/post/236375/
Попробуйте с помощью этой реализации решить эту задачу
Здравствуйте, samius, Вы писали:
S>>>С каких пор в фп нет очереди? BFE>>С самого начала. S>>>Не, ну список есть, а очереди — нет?! BFE>>И списка нет. S>Заявления такой степени абсурда, что их и опровергать как-то неудобно даже.
Ну так потому, что это не возможно, поэтому и не опровергните.
В фп нет структур, там есть только последовательности операций, некоторые из которых принято называть "список", "очередь"...
S>>>Как так? BFE>>Есть только тот или иной порядок работы с параметрами, который условно можно понимать как очередь, список и т.д.. S>Этот пассаж, боюсь, не понял. Переводить не нужно.
Значит вы не понимаете, что называется ФП.
И каждый день — без права на ошибку...
Re[20]: Мнение: объектно-ориентированное программирование — катастрофа на трилли
BFE>Этот контракт предполагает одновременное выполнение чтение и записи?
В ФП "одновременности" нет. BFE>Попробуйте с помощью этой реализации решить эту задачу
Эта модель используется вообще везде, гораздо ширше чем в ООП.Для примера — посимвольное копирование строки. 
