Здравствуйте, GarryIV, Вы писали:
GIV>А не делай развеситстые иерархии, зависимости аккуратно прокидывай (а то синглетоны тоже "удобно") и тд.
Их делают не от балды — а потому что они существуют в реальном мире. И если вы сделаете вид что в реально мире их не существуют — они не исчезнут и никуда не денутся. Просто вам придется их эмулировать, увеличивая количество сущностей + писать кучу бойлерплейт кода — в каждом из наследников вручную указывать всю иерархию.
В итоге все это невозможно будет поддерживать. Уже привели вам — количество строк кода увеличивается в разы, читаемость снижается.
GIV>Глядишь в какой то момент обнаржишь вокруг фей и прочих единорогов )
Нет, не обнаружишь. Говно никуда не денется, если отключить канализацию. Проблема не в канализации.
GIV>Как говорил профессор GIV>
GIV>«Если я, входя в уборную, начну мочиться мимо унитаза и то же самое будут делать Зина и Дарья Петровна, в уборной начнется разруха. Следовательно, разруха не в клозетах, а в головах!»
Здравствуйте, GarryIV, Вы писали:
S>>Некоторые говорят то что в Rust нет наследования реализаций — норм. А вы как думаете? GIV>наследования реализаций — зло GIV>композиция — добро
Кто сказал? Мы на практике видим обратное — передовые проекты используют наследование реализаций и это удобно.
Здравствуйте, Shmj, Вы писали:
S>дин из самых популярных в мире — и там именно наследование реализаций для ключевого функционала.
такого говна в количестве кругом и гордится тут нечем
Здравствуйте, Shmj, Вы писали:
S>Некоторые говорят то что в Rust нет наследования реализаций — норм. А вы как думаете?
Тупая мода, которая скоро пройдёт. Но так легче делать язык и перекладывать геморрой на программистов. Поэтому Rust не один такой (я считаю ещё как минимум Go, потому что наследование в нём убогое).
Но на переход маятника в обратном направлении нужно ещё лет пять.
Здравствуйте, dsorokin, Вы писали:
S>>Просто наследование — удобно, меньше бойлерплейт, красивее и проще код. Но чуть сложнее порог входа. Пример привел. D>Писать-то, конечно, проще. В этом и проблема
Не только писать проще — и читать намного проще. Меньше бойлерплейт и визуального мусора.
Минус один — выше порог входа. Т.е. многие банально не понимают что такое наследование. Помню как одному челу показал как в абстрактном классе оперирую методами, которых еще нет — у него округлились глаза.
Т.е. проблема сейчас — люди не хотят тратить время на вхождение, хотят просто писать.
D>Когда накапливается опыт использования, то люди начинают видеть, что сработало, а что — нет. Вот, рестарты из лиспа не пошли в дело. Еще что-то не пошло из других языков. Сейчас некоторые ставят под сомнение вот то, о чем ты так озаботился в этом треде. Это же не злые какие дяди так делают. Просто анализируют, смотрят, пробуют. Потом после них придут другие, которым тоже что-то не понравится. И так по кругу
Это не просто пошло а стало основой. Пример из реального репа с 5-уровневым наследованием привел.
Здравствуйте, Shmj, Вы писали:
S>Некоторые говорят то что в Rust нет наследования реализаций — норм. А вы как думаете?
наследования реализаций — зло
композиция — добро
Здравствуйте, antropolog, Вы писали:
A>я помню точно, что как минимум это было сказано в книге банды чётырёх про паттерны, в той части (в начале книги) где идут рассуждения об ООП-дизайне в целом. А книге, стесняюсь сказать, уже 30 лет. Ну т.е. это уже давно common knowledge, вроде как A>ну и гугл в ai режиме вполне неплохую выдачу даёт
Попробуйте по взрослому — возьмите последнюю Pro модель и спросите в чем плюсы и минусы каждого из подходов:
Когда удобнее C++ с многоуровневым наследованием
Framework-архитектуры (GUI, CAD, большие движки), где:
есть устойчивая иерархия объектов,
много “hook’ов” и виртуальных переопределений,
важна совместимость с существующими интерфейсами/ABI.
Большие существующие кодовые базы и экосистемы, уже построенные на наследовании (Qt, часть игровых/рендеринг движков, плагины под конкретные SDK).
Случаи, когда переиспользование реализации через базовый класс даёт максимальный выигрыш и команда дисциплинированно управляет сложностью (правила владения, запрет MI где не надо, аккуратный дизайн виртуальных интерфейсов).
Здравствуйте, GarryIV, Вы писали:
S>>Kotlin — 2010 S>>- везде есть классическое многоуровневое наследование
GIV>Есть конечно иначе им бы это мешало и код из жабы мигрировать и интероп затруднило и learning curve увеличило.
Это мнение. Не только Kotlin — я же и другие привел.
Просто наследование — удобно, меньше бойлерплейт, красивее и проще код. Но чуть сложнее порог входа. Пример привел.
Вообще приятно когда язык низкоуровневый, но позволяет многоуровневое наследование с виртуальными членами Как бы пишешь и приятно.
Здравствуйте, Shmj, Вы писали:
S>Просто наследование — удобно, меньше бойлерплейт, красивее и проще код. Но чуть сложнее порог входа. Пример привел.
Писать-то, конечно, проще. В этом и проблема
Когда накапливается опыт использования, то люди начинают видеть, что сработало, а что — нет. Вот, рестарты из лиспа не пошли в дело. Еще что-то не пошло из других языков. Сейчас некоторые ставят под сомнение вот то, о чем ты так озаботился в этом треде. Это же не злые какие дяди так делают. Просто анализируют, смотрят, пробуют. Потом после них придут другие, которым тоже что-то не понравится. И так по кругу
я не понял вашу сентенцию по-поводу "попробовать по взрослому". вы спросили кто это сказал — я ответил, что это было в банде четырёх 30 лет назад. Чтобы не лезть в книгу скопировал недостатки наследования реализации из гугла. К чему ваш ответ и зачем он мне и зачем мне что-то пробовать я вообще не понял.
Здравствуйте, Shmj, Вы писали:
S>Не только писать проще — и читать намного проще. Меньше бойлерплейт и визуального мусора.
S>Минус один — выше порог входа. Т.е. многие банально не понимают что такое наследование. Помню как одному челу показал как в абстрактном классе оперирую методами, которых еще нет — у него округлились глаза.
S>Т.е. проблема сейчас — люди не хотят тратить время на вхождение, хотят просто писать.
А я видел такой "ООП-код", что лучше бы авторы и не "знали" о том, что такое наследование классов, и что такое виртуальные методы. Причем, сам код был рабочий, оттестированный, проверенный в "полевых условиях". Да, и лучше бы не знали, что такое инлайн, а то у меня пестрило в глазах от этого слова
Тут понимаешь, такое дело. Что иногда лучше забрать игрушку, а то могут сделать что-то не то. Вот, ООП — это такая игрушка, которой еще нужно уметь пользоваться. Часто лучше, чтобы люди банально писали в стиле структурного программирования. И мне кажется, что современное программирование намеренно идет по пути упрощения, особенно учитывая популяризацию профессии, когда требования ко входу в IT все ниже и ниже (про C++ промолчим. Он идет своим путем — там много сложности совсем не из-за самой области системного программирования, а на мой взгляд, что там много сложности больше из-за груза прежних решений, на которых когда-то был построен фундамент языка. Особенно мне кажутся сложными шаблоны и особенно после уймы потраченного мною на них времени. Причем, что самое забавное, многие программисты C++ даже и не подозревают о сложности языка, на котором сами пишут. Обычно ухватятся за какую-то часть С++11 или C++14 и этим ограничиваются. Может быть, что к лучшему)
Здравствуйте, dsorokin, Вы писали:
D>Тут понимаешь, такое дело. Что иногда лучше забрать игрушку, а то могут сделать что-то не то.
Это взгляд с одной стороны — "я видел говнокод, потому что кто-то не осилил ООП".
А с другой стороны, не существует ни одного крупного проекта на растах и гошках, которые не были бы внутренними проектами компаний, заточенными на решение конкретной здачи. Т.е. ту задачу, которая решалась при помощи ООП в том же Qt, эти программисты вообще не решают — им главное наговнокодить, чтобы работало в ближайшие три года.
Здравствуйте, GarryIV, Вы писали:
S>>дин из самых популярных в мире — и там именно наследование реализаций для ключевого функционала. GIV>такого говна в количестве кругом и гордится тут нечем
Говно — это отражение нашего мира. Наш мир не может существовать без говна — попробуй канализацию отключить и пожить без нее. Это важнейшая часть нашего мира, на которой зиждется все живое.
Я понимаю что воняет, что неприятно — хотелось бы жить в мире фей и эльфов. Но так не бывает
ООП — это как канализация — это система по управлению говном. Если ты отключишь канализацию — говно не исчезнет, но управлять им станет намного сложнее и вони будет больше. Аналогично — убери ООП — говно из кода не исчезнет, просто управлять им станет намного сложнее — оно будет просачиваться из всех щелей.
Здравствуйте, Shmj, Вы писали:
S>Я понимаю что воняет, что неприятно — хотелось бы жить в мире фей и эльфов. Но так не бывает
А не делай развеситстые иерархии, зависимости аккуратно прокидывай (а то синглетоны тоже "удобно") и тд.
Глядишь в какой то момент обнаржишь вокруг фей и прочих единорогов )
Как говорил профессор
«Если я, входя в уборную, начну мочиться мимо унитаза и то же самое будут делать Зина и Дарья Петровна, в уборной начнется разруха. Следовательно, разруха не в клозетах, а в головах!»
Здравствуйте, Shmj, Вы писали:
GIV>>А не делай развеситстые иерархии, зависимости аккуратно прокидывай (а то синглетоны тоже "удобно") и тд.
S>Их делают не от балды — а потому что они существуют в реальном мире.
Нет дерево и близко не отражает реальный мир. В этом и проблема наследования реализаций.
Стивен Вольфрам использует гиперграфы чтобы симулировать "реальный мир" — что-то даже получается.
Здравствуйте, netch80, Вы писали:
N>Тупая мода, которая скоро пройдёт. Но так легче делать язык и перекладывать геморрой на программистов. Поэтому Rust не один такой (я считаю ещё как минимум Go, потому что наследование в нём убогое). N>Но на переход маятника в обратном направлении нужно ещё лет пять.
Здравствуйте, GarryIV, Вы писали:
S>>Их делают не от балды — а потому что они существуют в реальном мире. GIV>Нет дерево и близко не отражает реальный мир. В этом и проблема наследования реализаций.
GIV>Стивен Вольфрам использует гиперграфы чтобы симулировать "реальный мир" — что-то даже получается.
Реальный мир — он большой и разный. Где-то ООП не нужно и будет излишним. Где-то достаточно дерева. А где-то уже и дерева не достаточно.
Есть много задач, для решения которы ООП как раз подходит. Притом что люди (олды, да) к этому привыкли.
Здравствуйте, Shmj, Вы писали:
S>Есть много задач, для решения которы ООП как раз подходит. Притом что люди (олды, да) к этому привыкли.
Ловко ты с наследования на ООП спрыгнул. А ООП да годная вещь.
Здравствуйте, GarryIV, Вы писали:
S>>Есть много задач, для решения которы ООП как раз подходит. Притом что люди (олды, да) к этому привыкли. GIV>Ловко ты с наследования на ООП спрыгнул. А ООП да годная вещь.
Многоуровневое наследование важно для многих задач — пример привел. Не обязательно пихать везде, но когда его нет — GUI полноценно не напишешь.
Здравствуйте, Shmj, Вы писали:
S>Если наследование многоуровневое — по цепочке — тогда везде вам вручную нужно указывать какую версию использовать.
Hint: Новые языки стараются делать так чтоб правильный код было писать проще а неправильный сложнее.
Здравствуйте, GarryIV, Вы писали:
S>>Если наследование многоуровневое — по цепочке — тогда везде вам вручную нужно указывать какую версию использовать. GIV>Hint: Новые языки стараются делать так чтоб правильный код было писать проще а неправильный сложнее.
Kotlin — 2010
Dart — 2011
Swift — 2014
— везде есть классическое многоуровневое наследование
Тут скорее другое. Новые языки разрабатывают под конкретную задачу. Сделать одновременно и низкоуровневый и мультипарадигменный — почти никогда не стоит задача, да и сложно это.
Здравствуйте, Shmj, Вы писали: S>Кто сказал? Мы на практике видим обратное — передовые проекты используют наследование реализаций и это удобно.
я помню точно, что как минимум это было сказано в книге банды чётырёх про паттерны, в той части (в начале книги) где идут рассуждения об ООП-дизайне в целом. А книге, стесняюсь сказать, уже 30 лет. Ну т.е. это уже давно common knowledge, вроде как
ну и гугл в ai режиме вполне неплохую выдачу даёт
гугл ллм ответ
Implementation inheritance is often considered a bad practice or "anti-pattern" because it prioritizes code reuse at the cost of architectural flexibility. Modern software development generally favors composition over inheritance to create more maintainable and modular systems.
Core Problems with Implementation Inheritance
Tight Coupling: Subclasses become deeply dependent on the internal implementation of the superclass. Changes to the parent class can inadvertently break functionality in all its children, a phenomenon known as the Fragile Base Class Problem.
Violates Encapsulation: Inheritance often forces the parent class to expose internal details (via protected members) that should otherwise remain hidden, making the system harder to change and more vulnerable to bugs.
Rigid Hierarchies: Once a class is part of a deep inheritance tree, it is bound to that structure. This makes it difficult to adapt to new requirements that don't fit the original "is-a" model.
Forced Behavior (Inappropriate Reuse): Developers often use inheritance to "borrow" a few methods, but the subclass ends up inheriting all the parent's data and methods, even those it doesn't need. For example, inheriting a Stack from an ArrayList exposes inappropriate list operations (like insert(at_index)) that violate the stack's logic.
Increased Complexity: Deep inheritance chains (e.g., 5+ layers) make it extremely difficult to track where specific behavior is implemented, leading to code that is opaque and hard to debug.
Здравствуйте, Shmj, Вы писали:
S>Kotlin — 2010 S>- везде есть классическое многоуровневое наследование
Есть конечно иначе им бы это мешало и код из жабы мигрировать и интероп затруднило и learning curve увеличило.
Но по умолчанию там все классы final в терминах жабы (нельзя наследоваться).
Плюс там есть и плюшки для того чтоб композция более органично выглядела,
Как раз я об этом и говорил
Здравствуйте, dsorokin, Вы писали:
= D>А я видел такой "ООП-код", что лучше бы авторы и не "знали" о том, что такое наследование классов, и что такое виртуальные методы. Причем, сам код был рабочий, оттестированный, проверенный в "полевых условиях". Да, и лучше бы не знали, что такое инлайн, а то у меня пестрило в глазах от этого слова
Испортить можно любую идею...
D>Тут понимаешь, такое дело. Что иногда лучше забрать игрушку, а то могут сделать что-то не то. Вот, ООП — это такая игрушка, которой еще нужно уметь пользоваться. Часто лучше, чтобы люди банально писали в стиле структурного программирования.
Возможно кому-то и лучше — пусть каждый решает за себя.
Здравствуйте, student__, Вы писали:
__>Это взгляд с одной стороны — "я видел говнокод, потому что кто-то не осилил ООП". __>А с другой стороны, не существует ни одного крупного проекта на растах и гошках, которые не были бы внутренними проектами компаний, заточенными на решение конкретной здачи. Т.е. ту задачу, которая решалась при помощи ООП в том же Qt, эти программисты вообще не решают — им главное наговнокодить, чтобы работало в ближайшие три года.
Qt мне нравится, в целом. Хорошая библиотека. Только немного инородная для C++
И на моем макбуке от 2013 года приложения на Qt страшно мылились... Поэтому я потерял интерес к Qt в свое время, как и к Java SWT, когда купил себе макбук. Не знаю, починили в Qt это сейчас или нет? Мне просто интересно
На линуксе Qt выглядит хорошо, особенно на KDE. В винде — средне, но там в винде почти все выглядит средне
Здравствуйте, student__, Вы писали:
__>А с другой стороны, не существует ни одного крупного проекта на растах и гошках, которые не были бы внутренними проектами компаний, заточенными на решение конкретной здачи.
Хм. А Docker и Kubernetes — они внутренние проекты какой компании? Или они недостаточно крупные?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, student__, Вы писали:
__>>А с другой стороны, не существует ни одного крупного проекта на растах и гошках, которые не были бы внутренними проектами компаний, заточенными на решение конкретной здачи. S>Хм. А Docker и Kubernetes — они внутренние проекты какой компании? Или они недостаточно крупные?
Здравствуйте, НепредставимыйПхы, Вы писали:
НП>docker — dotCloud НП>k8s — Google
Тогда я, наверное, неправильно понимаю термин "внутренний". Можете показать примеры "крупных внешних проектов, не заточенных на решение конкретной задачи"?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Тогда я, наверное, неправильно понимаю термин "внутренний". Можете показать примеры "крупных внешних проектов, не заточенных на решение конкретной задачи"?
Внутренний — это когда компании пилят что-то для себя, а потом выкидывают в народ, внешний — наоборот. Как пример — linux kernel.
Здравствуйте, НепредставимыйПхы, Вы писали:
НП>Внутренний — это когда компании пилят что-то для себя, а потом выкидывают в народ, внешний — наоборот. Как пример — linux kernel.
Ну вот кубер сразу стартовал как открытый проект. То, что он основывался на идеях внутренних проектов — ну так и linux kernel начался как реимпплементация миникса.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Как бы пишешь и приятно.
