Здравствуйте, 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>Или это про то, что можно вызвать у объекта неизвестный на этапе написания программы метод, а объект в рантайме как-то разберется как его выполнять (т.е. сугубая динамика)?

И это в том числе.

A>Кстати, отсюда:
A>

A>OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

A>"Еxtreme late-binding of all things" не подразумевает ли динамику всегда и во всем?

Почти. Но никто тебе не запрещает эту динамику типизировать.

Здравствуйте, 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>Или это про то, что можно вызвать у объекта неизвестный на этапе написания программы метод, а объект в рантайме как-то разберется как его выполнять (т.е. сугубая динамика)?

И это в том числе.

A>Кстати, отсюда:
A>

A>OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

A>"Еxtreme late-binding of all things" не подразумевает ли динамику всегда и во всем?

Почти. Но никто тебе не запрещает эту динамику типизировать.