История изменений

Наследование реализации позволяет переиспользовать реализацию. Инкапсуляция обозначает сокрытие реализации. Следовательно при использовании наследования реализации инкапсуляция отсутствует.

Разве инкапсуляция protected отсутствует для внешних пользователей класса?

protected - скрыто от внешнего мира, но доступно наследникам - частичная инкапсуляция

А если реализация выполнена в private методах, то полная инкапсуляция отсуствует?

Есть несколько сторон в каждой проблеме: одна верная, другая нет, но посередине — всегда зло.

Это твои фантазии. При правильном использовании посредине - обоюдовыгодный компромис, а не зло.

Частичная инкапсуляция — это просто состояние неопределённости.

Откуда неопределённость? Protected доступ подробно определён в документации. Опять твои фантазии.

«Database может отправлять запросы, но ещё ты можешь унаследоваться и вмешаться в пул задач» — это не частичная инкапсуляция.

Скорее принимать запросы? И не database, а DBMS?

Унаследовать Database ?

Я назвал общеизвестный факт, не сам придумал. Проблемы действительно нет, если учитывать, что наследование реализации и инкапсуляция не сочетаются сами по себе.

Ну как же не сочетаются при использовании protected и private?

Ну а без инкапсуляции тоже можно работать, если аккуратно.

А зачем, когда есть private?

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

Опытному ООП разработчику легче создать корректную иерархию сразу на старте проекта?

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

Наследование - это один из инструментов. Требования проекта разве регламентируют его использование?

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

IMHO очень неудачный пример. Вася больше подходит в качестве экземпляра класса Human, у которого могут быть свойства, описывающие его Reading и Medical особенности и предпочтения.

Поэтому у опытного программиста особых перимуществ перед начинающим нет в выборе иерархии нового проекта, если только это не throwaway прототип.

Очень спорно, не согласен с тобой.

Ну а в C++ это считается хорошей практикой, поэтому и добавили в язык.

С чего ты взял, что то, что добавляется в C++, считается хорошей практикой всеми пользователями C++?

https://stackoverflow.com/questions/406081/why-should-i-avoid-multiple-inheritance

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

Поэтому и не стали добавлять ни в Java, ни в C#. Думаешь, С++ чем то лучше подходит для multiple inheritance по сравнению с шарпом?

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

Есть реальные популярные проекты, которые его используют?

В Event и Day уже происходят механики, жёстко привязанные к особенностям Subscribable.

Это твоя очередная архитектурная ошибка ?

Повторюсь, мои аргументы общеизвестны, я не сам их придумал.

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

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

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

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

Ты можешь разработать WinForms, WPF, Avalonia UI без наследования? Вспомни хотя бы посмешище GObject, что из этого получилось?

Я привёл достаточно примеров, чтобы это не казалось субъективными предпочтениями.

Твои примеры являются примерами архитектурных ошибок при ООП.

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

По твоему нет инструментов, которые измеряют степень переиспользования кода, эффективность применения ООП наследования и т.п.?

Нужны кому? Наследование — один подход, не единственный и не всегда верный.

Тем, кто извлекает выгоду от снижения затрат времени на программирование с ООП наследованием.

игнорируешь очевидные решения проблем Где?

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

А что там учитывать? Мы обсуждаем наследование само по себе.

Как я уже упоминал, некоторые домены разрабатывать без наследования особенно тяжело и трудоёмко.

А я привёл достаточно много аргументов в поддержку своих убеждений.

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

Многие твои якобы «проблемы наследования» - это проблемы неумелого использования, а не самого механизма.

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

Любые инструменты могут перестать правильно работать, если их неправильно применять.

Так субъективные предпочтения или рационализация? Рационализация обозначает ложное логическое объяснение поведению или подходу. То есть ложь. Такие вещи нужно доказывать.

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

Наследование реализации позволяет переиспользовать реализацию. Инкапсуляция обозначает сокрытие реализации. Следовательно при использовании наследования реализации инкапсуляция отсутствует.

Разве инкапсуляция protected отсутствует для внешних пользователей класса?

protected - скрыто от внешнего мира, но доступно наследникам - частичная инкапсуляция

А если реализация выполнена в private методах, то полная инкапсуляция отсуствует?

Есть несколько сторон в каждой проблеме: одна верная, другая нет, но посередине — всегда зло.

Это твои фантазии. При правильном использовании посредине - обоюдовыгодный компромис, а не зло.

Частичная инкапсуляция — это просто состояние неопределённости.

Откуда неопределённость? Protected доступ подробно определён в документации. Опять твои фантазии.

«Database может отправлять запросы, но ещё ты можешь унаследоваться и вмешаться в пул задач» — это не частичная инкапсуляция.

Скорее принимать запросы? И не database, а DBMS?

Унаследовать Database ?

Я назвал общеизвестный факт, не сам придумал. Проблемы действительно нет, если учитывать, что наследование реализации и инкапсуляция не сочетаются сами по себе.

Ну как же не сочетаются при использовании protected и private?

Ну а без инкапсуляции тоже можно работать, если аккуратно.

А зачем, когда есть private?

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

Опытному ООП разработчику легче создать корректную иерархию сразу на старте проекта?

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

Наследование - это один из инструментов. Требования проекта разве регламентируют его использование?

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

IMHO очень неудачный пример. Вася больше подходит в качестве экземпляра класса Human, у которого могут быть свойства, описывающие его Reading и Medical особенности и предпочтения.

Поэтому у опытного программиста особых перимуществ перед начинающим нет в выборе иерархии нового проекта, если только это не throwaway прототип.

Очень спорно, не согласен с тобой.

Ну а в C++ это считается хорошей практикой, поэтому и добавили в язык.

С чего ты взял, что то, что добавляется в C++ считается хорошей практикой всеми пользователями C++?

https://stackoverflow.com/questions/406081/why-should-i-avoid-multiple-inheritance

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

Поэтому и не стали добавлять ни в Java, ни в C#. Думаешь, С++ чем то лучше подходит для multiple inheritance по сравнению с шарпом?

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

Есть реальные популярные проекты, которые его используют?

В Event и Day уже происходят механики, жёстко привязанные к особенностям Subscribable.

Это твоя очередная архитектурная ошибка ?

Повторюсь, мои аргументы общеизвестны, я не сам их придумал.

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

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

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

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

Ты можешь разработать WinForms, WPF, Avalonia UI без наследования? Вспомни хотя бы посмешище GObject, что из этого получилось?

Я привёл достаточно примеров, чтобы это не казалось субъективными предпочтениями.

Твои примеры являются примерами архитектурных ошибок при ООП.

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

По твоему нет инструментов, которые измеряют степень переиспользования кода, эффективность применения ООП наследования и т.п.?

Нужны кому? Наследование — один подход, не единственный и не всегда верный.

Тем, кто извлекает выгоду от снижения затрат времени на программирование с ООП наследованием.

игнорируешь очевидные решения проблем Где?

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

А что там учитывать? Мы обсуждаем наследование само по себе.

Как я уже упоминал, некоторые домены разрабатывать без наследования особенно тяжело и трудоёмко.

А я привёл достаточно много аргументов в поддержку своих убеждений.

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

Многие твои якобы «проблемы наследования» - это проблемы неумелого использования, а не самого механизма.

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

Любые инструменты могут перестать правильно работать, если их неправильно применять.

Так субъективные предпочтения или рационализация? Рационализация обозначает ложное логическое объяснение поведению или подходу. То есть ложь. Такие вещи нужно доказывать.

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