Search
Write a publication
Pull to refresh

Comments 57

Автор, кажется, путает ООП с "все хорошее". Заявление "switch с паттерн-матчингом – это и есть ортодоксальное ООП!" сродни по силе чему-нибудь вроде "ключевое слово class – это и есть ортодоксальное ООП!". Реализация switch и ООП - понятия, строго говоря, ортогональные.

Понятно, что механизм, похожий на современный switch-case, действительно существовал в Simula, однако из этого факта сделан неверный вывод.

Проблема, которую решают и полиморфизм ("ортодоксальное ООП"), и switch по типу, - это обработка разнородных данных. Но они решают ее с противоположных сторон. Это по сути что-то вроде Expression Problem.

Возвращение switch-case в современной Java - не столько возвращение к "ортодоксальному ООП", сколько признание, что оба подхода имеют право на жизнь.

Заявление "switch с паттерн-матчингом – это и есть ортодоксальное ООП!" сродни по силе чему-нибудь вроде "ключевое слово class – это и есть ортодоксальное ООП!".

Совсем недавно (по геологическим меркам) в джаваскрипте не было ключевого слова класс. Но ООП было, хоть и немного странное. Если бы джаваскрипт был первым популярным языком, в котором появилось ООП, то после добавления ключевого слова класс, многие задались бы вопросом, а не отход ли это от первоначальных идей. И вполне можно было бы сказать, что ключевое слово class – это и есть ортодоксальное ООП. Сославшись на древний, но в этой альтернативной вселенной не "взлетевший" С++.

Проблема, которую решают и полиморфизм ("ортодоксальное ООП"), и switch по типу, - это обработка разнородных данных. Но они решают ее с противоположных сторон

Ну и вот годами нам говорят, что решать обработку разнородных данных без полиморфизма это принципиальное нарушение ООП. А тут оказывается, что люди которые его создавали прямо сразу именно так и хотели писать код. И не видели в этом ничего страшного.

Возвращение switch-case в современной Java - не столько возвращение к "ортодоксальному ООП", сколько признание, что оба подхода имеют право на жизнь.

Да, но очень неожиданно, что это именно вовзращение первоначальной идеи, а не новьё, утащенное из Котлина со Скалой ))

Совсем недавно (по геологическим меркам) в джаваскрипте не было ключевого слова класс. Но ООП было, хоть и немного странное

Да, в этом и есть мой тезис). ООП - этой парадигма, switch с pattern-matching - по сути синтаксический сахар, class - ключевое слово, служащее реализации принципов ООП. Между этими тремя понятиями нет никакой иерархии (сlass keyword не является частью ООП, как и switch (не) является частью парадигмы).

А тут оказывается, что люди которые его создавали

Simula - это же не методичка и не спецификация ООП. Это один из первых языков, принципы ООП реализовавший. Точно так же, как

Ну и вот годами нам говорят, что решать обработку разнородных данных без полиморфизма это принципиальное нарушение ООП

...как и Страуструп не является источником истины об ООП (кстати, таких заявлений я сейчас не могу вспомнить, наверняка вы можете показать примеры?)

Еще раз хочу повториться: это ортогональные понятия. Чтобы придать веса моим словам, еще раз сошлюсь на теоретический базис - Expression Problem. К тому же, я в корне не согласен с вашим выводом о "возврате к ортодоксии". Java эволюционирует, а не возвращается к истокам. Понятно, что все новое - хорошо забытое старое, но вывод, который вы делаете, в том виде, в котором вы его делаете - максимально провокационный.

Simula - это же не методичка и не спецификация ООП.

Так и нет никакой спецификации, есть только доминирующая в Java мире школа, которая декларирует, что ООП это полиморфизм. Но если бы методичка была, то это был бы подход C++, именно так ООП ворвался в мир. Страуструп может не делал утверждений про полиморфизм, я тоже не помню, но не пропустил считчи в язык и я считаю, что это хорошо демонстрирует его точку зрения.

А вот Мартин статью написал, я кстати переводил. Вот она https://habr.com/ru/articles/474518/

К тому же, я в корне не согласен с вашим выводом о "возврате к ортодоксии". Java эволюционирует, а не возвращается к истокам.

Если бы не моя ненависть к диалектике, я бы сказал, что это очередной виток Гегелевкой спирали, звучит красиво ))

Наверное, я должен был явно сказать об основной претензии - вы подменяете понятия: смешиваете наличие конкретной языковой конструкции в ранней реализации ООП с сущностью парадигмы ООП. Отдельно есть парадигма, отдельно - ее реализации. А pattern matching этой парадигме ортогонален. Это может прозвучать так, будто я отстаиваю тезис, что pattern matching - отход от принципов ООП, но это такое же утрированное заявление, как ваше. Методологически верно и точно сказать, что это РАЗНЫЕ вещи.

Ну и раз вы используете слово "ортодоксальный", анекдотично отмечу, что наличие "inspect" не является догмой вроде "вот он, православный ООП".

Отдельно стоит пояснить, что я не спорю с идеей статьи и только рад последним изменениям в java, но настаиваю на ошибке в категоризации.

Возможно, надо раскрыть, почему я называю ПМ и ООП ортогональными понятиями?

Паттерн матчинг в свитчах провоцирует писать код, который не использует полиморфизм, то есть провоцирует к отходу от парадигмы ООП, вот что я хотел сказать.

Возможно, надо раскрыть, почему я называю ПМ и ООП ортогональными понятиями?

Мне была бы любопытна ваша точка зрения по вопросу, где точно надо использовать ПМ, а где точно надо использовать полиморфизм. Без краевых случаев, а вот где явно то, а где явно другое.

Паттерн матчинг в свитчах провоцирует писать код, который не использует полиморфизм

А наличие goto писать код с goto...

А наличие goto писать код с goto...

Собственно поэтому его и убрали

Кто? В Java он есть, но я не видел чтобы его кто-то использовал.

Кто?

Дизайнеры новых языков программирования. Чем младше язык, тем меньше вероятность, что там будет goto. А если и будет, то совсем не тот, я в языках из прошлого века

В Java он есть, но я не видел чтобы его кто-то использовал.

Он есть, но от того, как его использовали в C осталась только одна маленькая часть - прыжки по циклам. А другого ничего нет. Потому что если бы было, люди бы писали код, который Дийкстра в своё время предложил считать вредным

goto в Java зарезервирован, чтобы запретить, его нельзя использовать.
Иногда удобно применить частичный аналог - break на метку.

Имхо, "точно надо" неприменимо к опытным специалистам. Лично я стараюсь руководствоваться чисто здравым смыслом, не ставя четких рамок. Но как эталонный пример использования ПМ можно привести работу с sealed интерфейсами - туда это, на мой взгляд, вообще идеально вписывается

Но как эталонный пример использования ПМ можно привести работу с sealed интерфейсами

А эталонный пример для полиморфизма?

Shape, Circle и Rectangle)

Shape, Circle и Rectangle с подсчётом площади? Это ж как раз идеальный кейс для ПМ и sealed интерфейсов. Если у нас есть закрытый интерфейс Shape, у которого две реализации Circle и Rectangle, то для подсчёта площади можно сделать один метод, в котором switch с pattern matching и в ветках возвращается площадь, посчитанная по соответствующей формуле.

Это не только производительнее, но ещё и даёт программисту возможность понять, что формулы для посчёта площади круга и прямоугольника по большому счёту не отличаются ничем, кроме коеффициента, который можно хранить в таблице, рядом с этим же методом

Я привык использовать ПМ для внешних свойств (как пример в статье), а полиморфизм для описания внутренних свойств. Так вот площадь является внутренним свойством объекта и считается специфично для каждой фигуры. Если вы спросили мое мнение - вот оно. Спорить не готов)

Тогда получается полиморфизм вообще не нужен? Всегда же вместо него можно switch или таблицу использовать. Зачем столько десятилетий народу лапшу вешали? Так красиво все объясняли, и вот нате вам. Приходит приказ сверху "пишите switch, полиморфизм Всё".

Ну, вообще это не аргумент). Извините за пример, но так-то люди веками тряпочками подтирались, а потом появилась туалетная бумага и приказ сверху "пользуйтесь ей, тряпочки Всё"

А нет, не всегда. Сам себе отвечаю. Если тип неизвестен на стадии компиляции, только тогда получается полиморфизм необходим. В остальных случаях "пишите switch". Будем дописывать в портяночку. Есть в этом свой винтажный стиль и даже некое удобство. Размотал, прокрутил экранчики и все увидел, вместо того, чтобы по классам лазить. Это humor если что. На самом деле люблю полиморфизм и всякие OCP.

Это humor если что.

Это наше будущее ))

А если Эллипс меня вдруг обнаружится или треугольник?

Эллипс и треугольник точно так же считаются. Коеффициент умножить на один параметр, умножить на другой.

Площать треугольника - 0.5 * основание * высота
Площадь эллипса - pi * большая полуось * малася полуось

Практически одна и та же формула ))

Хорошо, пусть будет эллипс с эллиптической дыркой, или ещё сложнее - гиперболоид (седло) - в реальной жизни такое отступление от стандарта сплошь и рядом?

где точно надо использовать полиморфизм

  • Там, где у объектов есть единый интерфейс.

  • Там, где предполагается стороннее расширение. Пользователи некой сторонней библиотеки не в силах расширить её sealed классы.

где точно надо использовать ПМ

Там, где есть разница в данных, а не в поведении. Either на полиморфизме не сделаешь.

Там, где есть разница в данных, а не в поведении.

Ну вот пример с Shape, Circle и Rectangle, который обсуждали чуть выше. Добавить Polygon ещё какой-нибудь, чтобы он выглядел более-менее реалистичным. Данные разные, но подсчёт площади приводят как хрестоматийный пример применения полиморфизма

Either на полиморфизме не сделаешь.

Ну как. Допустим метод возвращает объект, который может быть ошибкой или нормальным значением. И надо выполнить один код, если это ошибка и другой, если это значение. Этот метод может принимать дополнительный аргумент, в котором будет объект, реализующий интерфейс с двумя методами. Один метод для действия, которое надо произвести, если случилась ошибка и другой для действия, которое надо сделать с нормальным результатом. Мне кажется вот так можно. Или я неправильно всё понял?

Ну вот пример с Shape, Circle и Rectangle

Я вам четко сформулировал на что обратить внимание: интерфейс и расширение. Вы это проигнорировали.

Допустим метод возвращает объект... Этот метод может принимать дополнительный аргумент

Так вы определитесь возвращает он ответ или принимает аргумент (callback с единым интерфейсом).

Или я неправильно всё понял?

Думаю, что вы отлично всё поняли, но решили дурочка включить.

Так вы определитесь возвращает он ответ или принимает аргумент (callback с единым интерфейсом).

Ну да, я тут коряво написал. У возвращаемого объекта должен быть метод типа orElse у Optional, который примет коллбэки. И результат будет примерно такой же как у ПМ.

Думаю, что вы отлично всё поняли, но решили дурочка включить.

Ну нет, я хотел сказать, что одну и ту же задачу можно решить и паттерн матчингом и полиморфизмом. И хочется увидеть пример, который явно решается только паттерн-матчингом. Про то, что решается только полиморфизмом, вы очень доходчиво и хорошо написали.

Возможно пример с Either тоже такой же хороший, я просто не понимаю. Но пока мне кажется, что можно тут заменить паттерн матчинг на колбеки, то есть полиморфизм.

У возвращаемого объекта должен быть метод типа orElse у Optional, который примет коллбэки

Вы шаблон Посетитель описали.

И результат будет примерно такой же как у ПМ.

Потому что Посетитель - это усложнённый switch case.

ЧТД

Думаю, что вы отлично всё поняли, но решили дурочка включить.

Довольно забавно, что независимо от включения дурачка у вашего собеседника плюс-минус получилось докопаться до сути, и если бы не ООП, то он бы почти изобрёл Boehm-Berarducci encoding.

В этой кодировке тип Either e a = Left e | Right a (вернее, для простоты, инстанциирование его с конкретными E и A) представляется как

Either E A ≅ ∀ X. (E → X) → (A → X) → X

Left e ≅ λf. λg. f e
Right a ≅ λf. λg. g a

match (Left e) = expr1
match (Right a) = expr2
≅
λeither. either (λe → expr1) (λa → expr2)

(аннотации типов расставьте по вкусу)

Если вы знакомы с Church encoding, то Boehm-Berarducci — это, считайте, типизированный Чёрч (но есть несущественные на этом уровне нюансы).

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

оказывается, что люди которые его создавали

Они создавали не ООП, у них была конкретная задача - симулятор, например.

мы обсуждали новые свитчи в Джаве - с паттерн-матчингом и деструктуризацией.

По-настоящему, это как называется? Гугл мне не нашел других ссылок, кроме вашей.

Прочтя про паттерн-матчинг, подумал о регулярках (регекспы).

Ну я понял, что речь о "полиморфизме без полиморфизма".

Полиморфизм предполагает, что код даже не подозревает с объектами каких типов работает на самом деле. А тут всё явно. Так что это уже не "полиморфизм без полиморфизма" , а "ООП без полиморфизма"

Код и не подозревает. Вы же отсвитчили типы данных.

Так в том куске в котором switch написан, перечислены все типы данных, которые может принимать переменная. То есть они должны быть известны на этапе сборки. А полиморфизм предполагает позднее связывание. Как и вообще ООП по Алану Кею

Вы дали коду только варианты обработки, вот он и работает, не подозревая на этапе сборки, что подадут на вход. Не так ли?

Нет так. Код не знает, какой объект будет на входе, но он знает, что это будет объект одного из перечисленных типов. А при использовании полиморфизма, единственное, что знает код, это что объект реализует какой-то конкретный интерфейс

По-моему, здесь какая-то путаница.

Не являюсь знатоком Java, но у меня устойчивое ощущение слишком вольной интерпретации.

Поздравляю! Вы воюете не туда.

Все намного проще. Pattern matching - это как и sealed classes, records и прочее - это история которая пришла в Java из функционального программирования.

А знаете почему? Потому что с годами оказалось что ООП не торт. Ну по крайне мере для серверного приложения, где главная задача обрабатывать данные а не состояния и там лучше подходит ФП. Java туда потихоньку двигается.

Главный архитектор Java Brian Goetz написал статью о том что ООП конечно мы уважаем и для каких то задач оно подходит но мы будем двигаться в сторону ФП.

Data Oriented Programming in Java

Не нужно заглядывать глубоко в прошлое, когда ответ перед носом.

Ну только Data Oriented Programming с функциональным программированием имеет примерно столько же общего, сколько с ООП. Рекорды имутабельные, имутабельность, конечно, ключевой компонент ФП, но не ключевой компонент Data Oriented Programming.

То о чём пишет Гётц это традиционный старый добрый процедурный подход. Данные отдельно, код, который их обрабатывает отдельно. Который да, де факто в серверных приложениях сейчас повсюду.

Ну только Data Oriented Programming с функциональным программированием имеет примерно столько же общего, сколько с ООП. Рекорды имутабельные, имутабельность, конечно, ключевой компонент ФП, но не ключевой компонент Data Oriented Programming.

То о чём пишет Гётц это традиционный старый добрый процедурный подход. Данные отдельно, код, который их обрабатывает отдельно. Который да, де факто в серверных приложениях сейчас повсюду.

Да неужели. А если дальше почитать?

Algebraic data types

This combination of records and sealed types is an example of what are called algebraic data types (ADTs). Records are a form of "product types", so-called because their state space is the cartesian product of that of their components. Sealed classes are a form of "sum types", so-called because the set of possible values is the sum (union) of the value sets of the alternatives. This simple combination of mechanisms -- aggregation and choice -- is deceptively powerful, and shows up in many programming languages. 

Но это разумеется совпадение.

  • неизменяемые структуры данных +

  • паттерн матрчинг +

  • алгебраические типы данных +

  • монадические типы вроде Optional +

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

А все потому что дальновидный Brian Goetz написал "Data Oriented Programming" видимо мудро предвосхищая что напиши он ФП то у фанатов ООП случиться истерика.

Меня поражает что во всех других языках ни у кого вообще нет проблем с тем что туда добавляют элементы ФП но только в Джаве происходит перевозбуждение от одной мысли что там может быть что-то не ООПшное.

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

В статье Гётц пишет, что ФП это когда всё это функция. Наверное он так и думает. И если бы он считал, что главное в истории с рекордами и паттерн матчингом это добавление в Джаву элементов ФП он бы так и сказал.

Подхода "всё это функция" в Джаве нет и не планируется, понятия чистых функций нет и не планируется, за сайд эффектами никто не следит и не собирается.

А все потому что дальновидный Brian Goetz написал "Data Oriented Programming" видимо мудро предвосхищая что напиши он ФП то у фанатов ООП случиться истерика.

Когда в Джаве появились лямбды и стримы, то радостные крики джава-программистов были слышны на весь Интернет. Циклы заменили стримами моментально, практически за ночь. Все открыто говорили и до сих пор говорят, что вот оно наше ФП в джаве, дайте ещё да побольше.

И фанатов ООП, которые хоть как-то бы это осудили было человека три. А таких, кто хотел вообще убрать ООП и оставить только ФП, таких много было. Специально для них даже писали статьи, что ФП и ООП вообще никак не мешают друг другу и живут мирно. Так что нет, джава-программисты любят элементы ФП всем сердцем. Кроме, может быть, имутабельности.

В статье Гётц пишет, что ФП это когда всё это функция. Наверное он так и думает. И если бы он считал, что главное в истории с рекордами и паттерн матчингом это добавление в Джаву элементов ФП он бы так и сказал.

А еще он пишет что в ООП все есть объект. В Java половина языка - это не объекты, следовательно Java вообще не ООП язык? Или всетаки нет?

Там никто не стесняется, все все понимают и даже в названиях можно это увидеть: map, filter, compose, identity, никто не стал ничего придумывать заимствовали честно. Также ни для кого не секрет что  паттерн матчинг это фича фп языков и в основе это оттуда пошло в другие языки. В ФП языка он по больше части нужен для работы с ADT. Удивительно но даже в тексте Гёца он прямо пишет про ADT, тоже одной из отличительных особенностей ФП. Но нет он не это имел ввиду разумеется, потому что не написал волшебное слово ФП.

Заходим для примера в оф документацию по Rust там не стесняясь:

We’ve already covered some other Rust features, such as pattern matching and enums, that are also influenced by the functional style. 

И только в Java добавляют все тоже самое что и все другие но нет, это с ФП не связано.

Подхода "всё это функция" в Джаве нет и не планируется, понятия чистых функций нет и не планируется, за сайд эффектами никто не следит и не собирается.

Полноценного ООП в Rust/Go нет и не планируется что не мешает иметь методы.

Подхода "всё это функция" в Clojure нет и не планируется, понятия чистых функций нет и не планируется, за сайд эффектами никто не следит и не собирается. Но тем не менее это типичный ФП язык.

Что мешает Java развиваться перенимая фичи из ФП но не становясь чистым ФП языком? Загадка.

Циклы заменили стримами моментально, практически за ночь.

Джава сообщество, особенно того старого формата приняло такое за одну ночь?
Не смешите мои тапочки, там у людей спустя годы истерика не проходила.

Что мешает Java развиваться перенимая фичи из ФП но не становясь чистым ФП языком?

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

Джава сообщество, особенно того старого формата приняло такое за одну ночь?

Да, моментально. Циклы поменялись в исходниках на стримы практически сразу. Многие вообще стали писать

Optional.ofNullable(something).ifPresent(something-> something.doSomething()) вместо

if (something != null) something.doSomething()

var, например, даже близко не получил такого распространения. Больше стримов, наверное, завирусился только Lombok, хотя по его поводу и правда встречается негатив.

Не смешите мои тапочки, там у людей спустя годы истерика не проходила.

Есть в интернете хотя бы одна статья по этому поводу? Хотя бы одна цитата? Только Бугаенко по этому поводу высказывался и его за это же и хейтят всем миром

Нужно заглядывать по ссылке, которую прикладываете

The techniques of OOP and data-oriented programming are not at odds; they are different tools for different granularities and situations. We can freely mix and match them as we see fit.

Я ваш прочитал:

Главный архитектор Java Brian Goetz написал статью о том что ООП конечно мы уважаем и для каких то задач оно подходит но мы будем двигаться в сторону ФП.

Приведите цитату из статьи по ссылке, где это сказано.

When we're modeling complex entities, OO techniques have a lot to offer us. But when we're modeling simple services that process plain, ad-hoc data, the techniques of data-oriented programming may offer us a straighter path.

Where OOP encourages us to use classes to model business entities and processes, smaller codebases with fewer internal boundaries will often get more mileage out of using classes to model data

Что-то не так? Да есть ООП, да оно решает определенные задачи со всем уважением и мы с ним будем дружить и дальше но ветер перемен дует в другую сторону. Почему не написано так прямо и я интерпретировал фразу? Потому что Brian Goetz пишет весьма дипломатично и естественно не будет в открытую заявлять что нам приоритет сейчас не очень ООП. Почему я интерпретирую статью так хотя там в лоб так не написано? Очень просто, достаточно посчитать количество нововведений например начиная с Java 7 связанных с ООП и с ФП и все станет очевидно в каком направлении все движется.

Что-то не так?

Да, с вашим изначальным утверждением про ФП - в статье ничего про это не сказано. Functional programming встречается там всего один раз и не является темой статьи.

Ваш же комментарий выше по поводу goto в Java:

Кто? В Java он есть, но я не видел чтобы его кто-то использовал.

Согласно Вашей же логике - нет, его там нет.

Или Вы имели в виду что в Java есть конструкции по смыслу представляющие из себя goto но называющиеся по другому? Ну окей.

Но если так, не очень понимаю претензию к моим комментариям где я пишут ровно тоже самое - в статье формально не упоминается ФП но по смыслу оно там есть?

Определитесь уже.

Статья интересная, было приятно почитать и изучить что-то новое. Вообще вопрос развития тенденций в IT сфере это отдельное поле для споров и рассуждений, из данной статьи я так понял что ООП возвращается к своей основе, оно и понятно история циклична.

Скажу больше субъективно, но всё же думаю, что если судить больше по общепринятым практикам, чем по определениям и принципам, то это всё же ближе к функциональному или типичному императивному программированию, чем к ооп.

Немного объясню, что имею ввиду:

В (типичном) ООП-стиле обычно принято реализовывать все функции "внутри" и использовать абстракции (интерфейсы):

interface ISomething{
  void DoSomething(IAnother that);
}

sealed class Smth1 : ISomething {
  public void DoSomething(IAnother that) {/*…*/}
}

abstract class Smth2 : ISomething {
  int i;
  public abstract void DoSomething(object that);
  public int DoAnother() {/*…*/}
}

Грубо говоря, интерфейс эквивалентен структуре, содержащей несколько readonly-полей-функций, а класс эквивалентен экземпляру этой структуры.

readonly record struct ISomething(
  Action<IAnother> DoSomething
);

readonly struct Smth1{
  public ISomething as_interface{get;}
  
}

//без приватных полей
readonly record struct Smth2{
  public ISomething as_interface{get; init;}
  public Func<int> DoAnother{get;},
}

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

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

struct Smth1 {/**/}
struct Smth2 {/**/}

enum SomeSmthINeedRightNow {
  Smth1(Smth1),
  Smth2(Smth2)
}

fn do_1st(this: Smth1) {/**/}
fn do_2nd(this: Smth2) {/**/}

fn do_1st_or_2nd(this: SomeSmthINeedRightNow) {
  match this{
    Smth1(this) {/**/}
    Smth2(this) {/**/}
  }
}

Грубо говоря, нечто, существующее ещё с самого C с тех пор когда был придуман switch{case: /**/}

В какой-то мере, конечно, да — сами интерфейсы/трейты/тайпклассы сами по себе являются енумами/юнионами с потенциальном бесконечным количеством вариантом, но как бы именно различие подхода в том, что в случае классических union, enum или sealed interface перебрать все варианты является полностью возможным, а в классическом (не-sealed) ООП возможно лишь взять и предположить класс испольщуя rtti, при том, возможно, не угадать.

Если что, я лишь больше философствую и в реальности в очень многих языках всё же используется смешанный подход — не всегда удобен ни самый верный условному solid ООП, ни самый неабстрактный классический подход.

И, безусловно, java молодцы, что добавили некое подобие дискриминированных юнионов к себе, даже при том, что язык вроде как любящий хранить консервативность.

Ортодоксальный ООП - это Smalltalk (и, пожалуй, Self - я про него слышал только то, что это Smalltalk, из которого удалили классы, т.е., вещь в духе JS).

Есть объекты (и только объекты - никаких примитивных типов, классы - тоже объекты, nil тоже объект), мы им посылаем сообщения. Switch'и и прочее ветвление на тему "если объект - экземпляр такого-то класса, то делай то-то" скорее признак дурного тона. Вы просто посылаете сообщение объекту, а то, как это будет обработано, зависит от класса объекта (или, для JS, приаттаченных к объекту функций).

Ну, объект в Smalltalk'е может даже сменить класс в рантайме, а любому классу даже в рантайме можно добавить/удалить/изменить методы. На всяких Java etc приходится страдать, громоздить неуклюжие конструкции из-за невозможности произвольно расширить классы (включая системные), но называть это ООП? Как говорится, Алан Кей совсем не имел это в виду, когда придумывал термин "ООП".

от Бярны

Бъярнэ

По его мнению она делала код менее модульным

Так и есть

идея типизированных структур из N полей

Так есть же ещё union (как минимум от Си) и всякие Варианты (в Дельфях).
А если уж совсем глубоко копать, чем сюда не подходит интерпретация плоской памяти в качестве того или иного типа (байта, символа, вещественного или слова) ещё в совсем бородатых временах, когда писали только на асме?

При разработке Simula норвежцы использовали идеи Энтони Хоара

Не готов спорить, но вот ещё одно необоснованное утверждение: на самом деле идея пришла из Рефала - это самый ПМ-ориентированный язык.

Sign up to leave a comment.