Здравствуйте, 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.
Здравствуйте, antropolog, Вы писали:
A>я помню точно, что как минимум это было сказано в книге банды чётырёх про паттерны, в той части (в начале книги) где идут рассуждения об ООП-дизайне в целом. А книге, стесняюсь сказать, уже 30 лет. Ну т.е. это уже давно common knowledge, вроде как A>ну и гугл в ai режиме вполне неплохую выдачу даёт
Попробуйте по взрослому — возьмите последнюю Pro модель и спросите в чем плюсы и минусы каждого из подходов:
Когда удобнее C++ с многоуровневым наследованием
Framework-архитектуры (GUI, CAD, большие движки), где:
есть устойчивая иерархия объектов,
много “hook’ов” и виртуальных переопределений,
важна совместимость с существующими интерфейсами/ABI.
Большие существующие кодовые базы и экосистемы, уже построенные на наследовании (Qt, часть игровых/рендеринг движков, плагины под конкретные SDK).
Случаи, когда переиспользование реализации через базовый класс даёт максимальный выигрыш и команда дисциплинированно управляет сложностью (правила владения, запрет MI где не надо, аккуратный дизайн виртуальных интерфейсов).
Здравствуйте, Shmj, Вы писали:
S>Kotlin — 2010 S>- везде есть классическое многоуровневое наследование
Есть конечно иначе им бы это мешало и код из жабы мигрировать и интероп затруднило и learning curve увеличило.
Но по умолчанию там все классы final в терминах жабы (нельзя наследоваться).
Плюс там есть и плюшки для того чтоб композция более органично выглядела,
Как раз я об этом и говорил
Здравствуйте, GarryIV, Вы писали:
S>>Kotlin — 2010 S>>- везде есть классическое многоуровневое наследование
GIV>Есть конечно иначе им бы это мешало и код из жабы мигрировать и интероп затруднило и learning curve увеличило.
Это мнение. Не только Kotlin — я же и другие привел.
Просто наследование — удобно, меньше бойлерплейт, красивее и проще код. Но чуть сложнее порог входа. Пример привел.
Вообще приятно когда язык низкоуровневый, но позволяет многоуровневое наследование с виртуальными членами Как бы пишешь и приятно.
Здравствуйте, Shmj, Вы писали:
S>Просто наследование — удобно, меньше бойлерплейт, красивее и проще код. Но чуть сложнее порог входа. Пример привел.
Писать-то, конечно, проще. В этом и проблема
Когда накапливается опыт использования, то люди начинают видеть, что сработало, а что — нет. Вот, рестарты из лиспа не пошли в дело. Еще что-то не пошло из других языков. Сейчас некоторые ставят под сомнение вот то, о чем ты так озаботился в этом треде. Это же не злые какие дяди так делают. Просто анализируют, смотрят, пробуют. Потом после них придут другие, которым тоже что-то не понравится. И так по кругу
Здравствуйте, dsorokin, Вы писали:
S>>Просто наследование — удобно, меньше бойлерплейт, красивее и проще код. Но чуть сложнее порог входа. Пример привел. D>Писать-то, конечно, проще. В этом и проблема
Не только писать проще — и читать намного проще. Меньше бойлерплейт и визуального мусора.
Минус один — выше порог входа. Т.е. многие банально не понимают что такое наследование. Помню как одному челу показал как в абстрактном классе оперирую методами, которых еще нет — у него округлились глаза.
Т.е. проблема сейчас — люди не хотят тратить время на вхождение, хотят просто писать.
D>Когда накапливается опыт использования, то люди начинают видеть, что сработало, а что — нет. Вот, рестарты из лиспа не пошли в дело. Еще что-то не пошло из других языков. Сейчас некоторые ставят под сомнение вот то, о чем ты так озаботился в этом треде. Это же не злые какие дяди так делают. Просто анализируют, смотрят, пробуют. Потом после них придут другие, которым тоже что-то не понравится. И так по кругу
Это не просто пошло а стало основой. Пример из реального репа с 5-уровневым наследованием привел.
я не понял вашу сентенцию по-поводу "попробовать по взрослому". вы спросили кто это сказал — я ответил, что это было в банде четырёх 30 лет назад. Чтобы не лезть в книгу скопировал недостатки наследования реализации из гугла. К чему ваш ответ и зачем он мне и зачем мне что-то пробовать я вообще не понял.
Здравствуйте, Shmj, Вы писали:
S>Не только писать проще — и читать намного проще. Меньше бойлерплейт и визуального мусора.
S>Минус один — выше порог входа. Т.е. многие банально не понимают что такое наследование. Помню как одному челу показал как в абстрактном классе оперирую методами, которых еще нет — у него округлились глаза.
S>Т.е. проблема сейчас — люди не хотят тратить время на вхождение, хотят просто писать.
А я видел такой "ООП-код", что лучше бы авторы и не "знали" о том, что такое наследование классов, и что такое виртуальные методы. Причем, сам код был рабочий, оттестированный, проверенный в "полевых условиях". Да, и лучше бы не знали, что такое инлайн, а то у меня пестрило в глазах от этого слова
Тут понимаешь, такое дело. Что иногда лучше забрать игрушку, а то могут сделать что-то не то. Вот, ООП — это такая игрушка, которой еще нужно уметь пользоваться. Часто лучше, чтобы люди банально писали в стиле структурного программирования. И мне кажется, что современное программирование намеренно идет по пути упрощения, особенно учитывая популяризацию профессии, когда требования ко входу в IT все ниже и ниже (про C++ промолчим. Он идет своим путем — там много сложности совсем не из-за самой области системного программирования, а на мой взгляд, что там много сложности больше из-за груза прежних решений, на которых когда-то был построен фундамент языка. Особенно мне кажутся сложными шаблоны и особенно после уймы потраченного мною на них времени. Причем, что самое забавное, многие программисты C++ даже и не подозревают о сложности языка, на котором сами пишут. Обычно ухватятся за какую-то часть С++11 или C++14 и этим ограничиваются. Может быть, что к лучшему)
Здравствуйте, dsorokin, Вы писали:
= D>А я видел такой "ООП-код", что лучше бы авторы и не "знали" о том, что такое наследование классов, и что такое виртуальные методы. Причем, сам код был рабочий, оттестированный, проверенный в "полевых условиях". Да, и лучше бы не знали, что такое инлайн, а то у меня пестрило в глазах от этого слова
Испортить можно любую идею...
D>Тут понимаешь, такое дело. Что иногда лучше забрать игрушку, а то могут сделать что-то не то. Вот, ООП — это такая игрушка, которой еще нужно уметь пользоваться. Часто лучше, чтобы люди банально писали в стиле структурного программирования.
Возможно кому-то и лучше — пусть каждый решает за себя.
Здравствуйте, dsorokin, Вы писали:
D>Тут понимаешь, такое дело. Что иногда лучше забрать игрушку, а то могут сделать что-то не то.
Это взгляд с одной стороны — "я видел говнокод, потому что кто-то не осилил ООП".
А с другой стороны, не существует ни одного крупного проекта на растах и гошках, которые не были бы внутренними проектами компаний, заточенными на решение конкретной здачи. Т.е. ту задачу, которая решалась при помощи ООП в том же Qt, эти программисты вообще не решают — им главное наговнокодить, чтобы работало в ближайшие три года.
Здравствуйте, 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 начался как реимпплементация миникса.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Как бы пишешь и приятно.
