Немного новостей из мира Rust

вы бредите.

Ну вот, теперь и вы заметили ;)

Еще этот персонаж судит о коде, не видя кода, и делает выводы из научных работ даже не читая их.

Еще одно интересное видео про наследование, пример на C# но применимо к любому языку

Ничего интересного. Это все на слуху еще со времен появления Java на рынке. Когда маркетологи Java стали доказывать, что множественное наследование – это фу-фу-фу, а вот одиночное наследование и специально выдуманные интерфейсы – вот прям то, что рынку и нужно.

Так что более правильно это видео озаглавить «The flaw of single inheritance» :)

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

Тут, правда, есть две проблемы:

1. Поддержка множественного наследования – это сложно. И для разработчика языка (поэтому она встречалась мне только в Eiffel и C++), и для пользователей языка.

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

Поддержка множественного наследования – это сложно. И для разработчика языка (поэтому она встречалась мне только в Eiffel и C++),

Питон поддерживает множественное наследование.

Спасибо, буду знать. У меня минимальный опыт общения с Python и написано на нем сильно меньше, чем на C++ и даже на Eiffel.

хватит болтать. лучше ответьте почему все пороки просто отношения - «использование»(смотри UML), вы перенесли именно на наследование?

Клован, тебе дали прямо практический пример. Ну ладно, академиев ты не кончал, но текст-то прочитать можешь? Можешь осознать, что есть таки разница, в случае декоратора будет поломка сборки, а в случае наследования - поломка логики работы виджета?

Ну вот и считай это волшебным свойством наследования.

А если захочешь выпендриться, можешь зазубрить «наследование нарушает инкапсуляцию».

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

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

Садись, двойка. В правильно спроектированном под современные требования ООП софте не может быть в принципе необходимости в совместимости с наследуемым классом, за это отвечает буква D в SOLID. Совместимость должна быть с интерфейсом. Т.е. с базовым классом предполагаемого «предка».

если такая совместимость не нужна - значит наследование избыточно и только путает читателя. тут нужна композиция.

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

для совсем тупых - КРИТИКА НАСЛЕДОВАНИЯ ЭТО КРИТИКА КОМПОЗИЦИИ,

Ещё раз, для совсем тупых: в мире где не различимы наследование и композиция не может быть причин предпочитать одно другому. Вот это простое правило хотя бы осознай, клован.

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

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

В ОО несколько другое дело, тут наследование одного от другого несёт смысл, а неконтролируемое перемешивание кода предка и потомка нарушает инкапсуляцию.

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

Отвечая цитатой великих, «Вам я советую вернуться в реальность. Если вам что-то просто и понятно, но оно противоречит тому что вам сообщает мир, то возможно оно на самом деле вам не слишком уж и понятно.» (c) khrundel

В правильно спроектированном под современные требования ООП софте не может быть в принципе необходимости в совместимости с наследуемым классом, за это отвечает буква D в SOLID.

Интересно, а как вы уживаетесь с тем, что ООП – это протухшее и никому не нужное говно, но при этом надрачиваете на SOLID и упоминаете какой-то «правильно спроектированный под современные требования ООП софт»?

Тем не менее, цитаты и ссылки мной приведены.

Пардон, а если это не полный слив, зачем вы считаете нужным оправдываться?

Любой желающий может сам пройтись по ним и составить собственное мнение: доказывают ли работы Барбары Лисков «полную несостоятельность ООП» или же, напротив, формируют более четкие критерии для ответа на вопрос «is-a»

Небольшое враньё с вашей стороны. Как обычно, собственно. Нужно было опровергнуть не утверждение «Барбара Лисков доказала полную несостоятельность ООП», а «принцип лисковой доказал полную несостоятельность ООП». Чувствуете разницу? Для этого недостаточно не найти в работах Лисковой утверждения «ООП несостоятельно». Тут, не много ни мало, надо спорить с утверждением что из принципа Лисковой следует несостоятельность ООП.

Но вся эта история

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

И все это, нужно отметить, в чистом ОО-языке. Подчеркну: в чистом , а не гибридном (вроде C++ или D). Несостоятельность ООП доказана полностью. Полностью! (это шутка, если что).

Наш ыксперд окончательно перешёл на «защиту чубакки». В 92 году написали статью о проблеме в чистом ООП-языке (а не гибридном, это очень важно!) и поэтому, господа присяжные заседатели, ООП состоятельно. Возразить что-то на представленные аргументы? Зачем? Главное же что в статье 92 года на 9й странице написали что-то по близкой теме. Читать всё равно никто не пойдёт, а если какой дурак реально попрётся читать, там действительно будет написано про наследование.

Сука, почему все такие тупые?

Маааам, ну почему эти казлы со мной не соглашаются? Я хочу, чтобы все со мной соглашались!!! Я же самый умный!! Я ХОЧУ!!

*топает ножками и пускает пузыри носом

зачем вы считаете нужным оправдываться?

Вы в моих словах оправдания увидели? О_о

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

Нужно было опровергнуть не утверждение «Барбара Лисков доказала полную несостоятельность ООП», а «принцип лисковой доказал полную несостоятельность ООП». Чувствуете разницу?

Да это же полностью меняет дело!

«принцип Лисков доказал полную несостоятельность ООП г.khrundel-ю»

Как доказал, чем доказал – пофиг, джентельменам же верят на слово. Главное, что khrundel видит какое-то доказательство.

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

вы от темы то не отклоняйтесь.

на вашу критику наследования мною были выдвинуты след. утверждения.

1. наследование класса в с++ и подобных ему языках(ява шарп и проч) есть композиция с объявлением совместимости наследника с наследуемым.

отсюда логически следует, что все «пороки наследования» переносятся автоматически и на композцию.

и отсюда уже следует, что пороки наследования это пороки композиции, поскольку наследование это просто композиция с «синтаксическим сахаром».

если вы критикуете наследование - вы должны критиковать и композицию. если вы при этом НЕ критикуете композицию, значит нечего и критиковать наследование. определитесь уже.

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

Портянки от хрюнделя впечатляют. Почти царский уровень. Мне правда не хватает терпения их читать, да и у царя смешнее получалось.

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

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

хрюнделя твоего ветер носит в разные стороны. он по моему даже часто не понимает, про что говорит.

тему он откровенно забалтывает.

Почти царский уровень.

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

Сам придумал проблему на умозрительном тулките, сам с ней поборолся, сам преодолел.

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

В этом заключается отличие сумасшедшего от просто туповатого.

Сильно не хватает примеров кода с царскими комментариями. Там был самый цимес.

В обсуждении ООП мало конкретики и много переходов на личности.

https://habr.com/ru/articles/451982/ Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

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

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

В обсуждении ООП мало конкретики и много переходов на личности.

Ну так здесь же в качестве доказательств приводят «мое оценочное суждение» и «хотя по мне всё очевидно», так что это неизбежно.

https://habr.com/ru/articles/451982/ Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

Еще один идиот решил выпендриться за счет кликбейтного заголовка, а другой притащил это сюда.

Повторюсь: ООП – это инструмент. И относиться к нем нужно как к инструменту, понимая его достоинства и недостатки, осознавая границы применимости.

Проблема ООП в том, что этот инструмент сперва возвели в ранг серебряной пули и стали жрать полной ложкой. Даже ЯП для мейнстрима сделали, в которых не было ничего, кроме ООП (это я про Java в первую очередь).

Естественно, наступила интоксикация.

Только проблема не в ООП, а в чрезмерном фанатизме, вроде максимы «в мире нет ничего, кроме объектов».

Вот от этой максимы нужно избавляться, а не от ООП.

Применительно к обсуждаемым здесь проблемам ООП имеет смысл привести цитату из Бертранда Мейера (который в ООП разбирается получше всех здесь отметившихся):

The combination of inheritance, redeclaration, polymorphism, and dynamic binding yields much of the power and flexibility that result from the use of the object-oriented approach. Yet these techniques may also raise concerns of possible misuse: What is to prevent a redeclaration from producing an effect that is incompatible with the semantics of the original version -fooling clients in a particularly bad way, especially in the context of dynamic binding? Nothing, of course. No design technique is immune to misuse. But at least it is possible to help serious designers use the technique properly; here the contract theory provides the proper perspective.

Ну да, если уж в ООП начали бросаться камнями с надписью «принцип подстановки Лисков», то следовало бы осознать, что этот принцип применим не только к ООП, но и, например, к обобщенному программированию.

Не утверждаю, что ОПП плох.
Для тех кто его любит он хорош и vs.
Для меня так вообще проблемы хорош или плох Си и C++ нет.
ЯП не повинны в том, что программисты пишут плохой код.

Надеюсь обсуждение продолжится.

ЯП не повинны в том, что программисты пишут плохой код.

Ошибаетесь.

ЯП предоставляют синтаксис для разработки алгоритмов и никоим образом не повинны в том, что алгоритмы могут быть «не очень».

ЯП предоставляют синтаксис для разработки алгоритмов и никоим образом не повинны в том, что алгоритмы могут быть «не очень».

Еще одним анонимным надмозгом больше…

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

Говнокод написать можно везде. Но где-то это делается вот вообще не напрягаясь и, что самое важное, с тяжелыми последствиями.

Язык может быть непригоден для выражения какой-либо абстракции.

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

А на крестах можно.

Ладно, сдаюсь.
«Языковые войны» - «не моё».

Сражайтесь.

я к тому, что существует два основных течения критики «ооп типа с++».

1. критика снизу, возникла еще в эпоху, когда ооп становилось мейнстримом. суть тезиза - «ооп не нужно, все можно и на си написать». это либерал-течение.

2. критика сбоку - ваш ооп слишком страшен, опасен и могуч,мы вам дадим такую мега парадигму(вот только название придумаем, кстати еще так и не придамали), где вы будете действовать строго по протоколу, это будет решением всех проблем… на самом деле они просто берут подмножество ооп в стиле с++, выникинув те фичи, которые их особенно пугали.

это - маоисты. их задача - ограничить, и дать новые названия старым понятиям, которое еще остались.

понятно что «либералы» и «маоисты» противоречат друг другу, поскольку один вообще отрицают ооп, а другие пытаются найти «правильное ооп», доводя само ооп до абсурда и слабой применимости в силу неудобств.

Спасибо!

Дружище, приятно читать позитивные посты.

Для меня ООП C++, это один из методов работы с данными.
Что касаемо критики ООП, то безусловно должна быть конкретика.

У меня интересно получилось в юности. Я знакомство с Си++ начал фактически раньше, чем с Си, и раньше, чем вообще с какими-то «базовыми» представлениями об этих ЯП. Я сразу начал с классической книги Джеффа Элджера, которая привлекла моё внимание в магазине. Про Си++ я ничего толком не знал в плане владения конкретным синтаксисом языка, а про Си - только самые основы.

Книга при вдумчивом чтении даёт понимание про проектирование как таковое, ну и в процессе приходится научиться читать синтаксис ЯП, чтобы понять идеи автора.

Такой вот жесткий старт)

Хотя в работе я с крестами сейчас не сталкиваюсь, другие ЯП преобладают. Вон даже добавление модулей пропустил.

Но при этом вижу, что направление эволюции языка в целом ровно то, что было заложено изначально.

Си++ - это не про алгоритмы, а про выражение смыслов.

Когда Си++ пытаются критиковать с той стороны, что это «плохой Лисп» или «плохой Хаскель» или «плохой <любая-другая-якобы-серебряная-пуля>» - это своего рода признание заслуг языка в области развития выразительных средств. Никому же не придёт в голову писать, что Си или Паскаль - это «плохой Хаскель» за очевидной абсурдностью такого сопоставления.

наследование класса в с++ и подобных ему языках(ява шарп и проч) есть композиция с объявлением совместимости наследника с наследуемым.

отсюда логически следует, что все «пороки наследования» переносятся автоматически и на композцию.

и отсюда уже следует, что пороки наследования это пороки композиции, поскольку наследование это просто композиция с «синтаксическим сахаром».

Птица это двуногое с объявлением покрытия перьями. Отсюда логически следует, что все пороки птицы переносятся автоматически и на двуногих. И отсюда уже следует, что пороки птиц это пороки двуногих, поскольку птица это просто двуногое с «синтаксическим сахаром».

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

Маааам, ну почему эти казлы со мной не соглашаются? Я хочу, чтобы все со мной соглашались!!! Я же самый умный!! Я ХОЧУ!!

Т.е. вы согласны с обоими упомянутыми ораторами по упомянутым вопросам? Или соратников в борьбе не выбирают, ну затупили пацаны, чё теперь?

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

Либо что-то не так со мной

Почему бы и нет.

Интересно, а как вы уживаетесь с тем, что ООП – это протухшее и никому не нужное говно, но при этом надрачиваете на SOLID и упоминаете какой-то «правильно спроектированный под современные требования ООП софт»?

Вам всерьёз непонятно как так получилось?

Ну что тут сказать, действительно с головой беда.

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

Почему бы и нет.

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

Как доказал, чем доказал – пофиг, джентельменам же верят на слово. Главное, что khrundel видит какое-то доказательство.

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

Тебя ещё и паранойя терзает?

вы от темы то не отклоняйтесь.

Обезоруживающая наглость.

наследование класса в с++ и подобных ему языках(ява шарп и проч) есть композиция с объявлением совместимости наследника с наследуемым.

Это не соответствует действительности. Соответственно и выводы неверные.

И, главное, я раза три уже объяснил почему. Но вам так нравится идея логической победы, что вы тупо повторяете раз за разом.

Тебя ещё и паранойя терзает?

Нет. Так всё-таки, готов подписаться под словами этих идиотов, или просто в сторонке постоишь?

Не трясись.

И этот значит слился.

Птица это двуногое с объявлением покрытия перьями. Отсюда логически следует, что все пороки птицы переносятся автоматически и на двуногих. И отсюда уже следует, что пороки птиц это пороки двуногих, поскольку птица это просто двуногое с «синтаксическим сахаром».

Вы пнули, вероятно, чуть ли не в главную проблему ООП: классификация.

Без удачной классификации реализация задачи быстро превращается в говно.

Причем, по большому счету, эта проблема присуща любым языкам, в которых есть что-то вроде trait или interface и где для своих типов эти trait/interface требуется реализовывать полностью. Т.е. уже во время написания своего типа A нужно понимать, какие из trait/interface потребуется реализовать для A.

Полагаю, что ситуация чуть проще в случае, когда интерфейс можно прицепить к типу неявно, как это делается в Go: если в типе A обнаружились методы, соответствующие интерфейсу I, то экземпляр A автоматически может выступать в качестве реализации I.

Полагаю, но не уверен.

Аргументы приведены, вы решили не отвечать и слиться.

Логическая нестыковка: нежелание отвечать не означает желание слиться.

Как и подведение промежуточной черты с добавлением еще одной важной ссылки не является оправданием.

Из ложных предпосылок вы в очередной раз получили и озвучили ложные выводы.

В общем я дам вам подсказку: всему виной принцип «разделяй и властвуй».

Не совсем так. Давайте нырнем глубже в этот омут.

Всему виной чувство меры, вернее его отсутствие. Меры в композиции и в декомпозиции, меры в строгости и в гибкости в изоляции кода, меры в типизации и тд и тп. Ведь когда есть баланс меры - реализация хоть на гендерно-нейтральном RUST, хоть на мужицком PHP будет хороша.

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

Поэтому нет смысла спорить что лучше - когда потолще или когда подлиннее. Лучше обмазываться и композицией и наследованием когда это уместно. Конкретно про ООП - он не лучше чего бы то ни было, ООП просто покрывает больший спектр задач с приемлемым уровнем меры, но ни в коем случае не является серебряной пулей.

Вам всерьёз непонятно как так получилось?

Было бы желательно. Но вряд ли вы сможете. Растечетесь в очередной раз мыслею по древу и все.

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

Напоминает байки о том, как пытались проектировать системы глобального гипертекста (предтечи нынешнего Web-а): камнем преткновения была невозможность гарантировать корректность сохранения валидности ссылок.

Потом пришел Тим Бернес-Ли и забил на попытки реализовать такие гарантии. Получился известный нам Web: по большей части работает, но что-то из него может пропасть.

Аналогично и с ООП: никто не дает вам абсолютных гарантий (хотя пример Eiffel доказывает, что можно очень близко подойти к реализации формальных признаков принципа подстановки Лисков в программном коде). Но с помощью ООП уже написана туева хуча полезного кода.

Кстати, не подскажите, какие гарантии соответствия принципу подстановки Лисков дают трейты в Rust-е?

https://wiki.c2.com/?OopArgumentsDebatesAndDiscussion Oop Arguments Debates And Discussion

И, главное, я раза три уже объяснил почему. Но вам так нравится идея логической победы, что вы тупо повторяете раз за разом.

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

спасибо.

первая половина, а также по цепочке упомянутый пример. Хотя какой смысл?