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

Наследование реализации, в свою очередь, расширяет понятие возможностью переиспользования реализации (разница между private и protected не столь важна).

Почему по твоему важно является ли метод реализацией, а не то, какой доступ ему назначен? И для чего важно?

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

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

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

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

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

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

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

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

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

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

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

[Множественное наследование не] считается хорошей практикой в отличие от немножественного наследования.

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

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

Разве нельзя было унаследовать Event и Day от IntenseSubscribable, а IntenseSubscribable от Subscribable ?

Иногда можно, иногда нет. Что если Subscribable — это уведомление на почту/календарь, а IntenseSubscribable — в какой-нибудь модный мессенджер?

Надо было сразу назвать этот пример, но упустил, сорри. Примерно такой пример я имел ввиду здесь:

Ты не можешь легко заменить Subscribable на, допустим, IntenseSubscribable — то же самое поведение, но с другой механикой.

В Event и Day уже происходят механики, жёстко привязанные к особенностям Subscribable. Например, подтверждение сделано через прослушивание сообщений. А в IntenseSubscribable пользователь нажимает кнопку, при этом никакое сообщение не отправляется.

Кроме того различные *able типа Subscribable обычно описываются интерфейсами, а не наследованием.

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

Это ты в ловушке, потому что не умеешь или делаешь вид, что не умеешь в ООП с наследованием.

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

IMHO главное [до сих пор идёт речь о количестве кода] определяется не разумом определённого человека, а целями проекта и эффективностью программирования.

Не определённого, но я и не говорил про определённого.

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

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

GUI, 3D графика, математика и т.п. В такого рода проектах implementation inheritance может сокращать количество кода в разы!

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

Ты апеллируешь к субъективным предпочтениям, а я - к объективным метрикам.

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

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

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

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

Где?

подменяешь технические аргументы своими философскими

Они не полностью мои. И разница между техникой и философией в нашем контексте несущественна. Эпистемология — наука, посвящённая поиску правильных методов получения и подтверждения знаний. Строительный блок ООП в современном понимании — понятие об абстракции, дошедшее до нас со времён Древней Греции. Да и большинство моих аргументов вполне соответствуют современным представлениям об ООП: is-a, has-a, отношения между абстракциями — это всё я взял не из философии.

не учитываешь специфику разных доменов

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

ты догматически против наследования

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

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

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

Мне кажется, что ты просто пытаешься рационализировать свою неопытность в ООП-дизайне.

Так субъективные предпочтения или рационализация?

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

Наследование реализации, в свою очередь, расширяет понятие возможностью переиспользования реализации (разница между private и protected не столь важна).

Почему по твоему важно является ли метод реализацией, а не то, какой доступ ему назначен? И для чего важно?

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

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

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

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

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

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

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

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

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

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

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

[Множественное наследование не] считается хорошей практикой в отличие от немножественного наследования.

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

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

Разве нельзя было унаследовать Event и Day от IntenseSubscribable, а IntenseSubscribable от Subscribable ?

Иногда можно, иногда нет. Что если Subscribable — это уведомление на почту/календарь, а IntenseSubscribable — в какой-нибудь модный мессенджер?

Надо было сразу назвать этот пример, но упустил, сорри. Именно этот пример я имел ввиду здесь:

Ты не можешь легко заменить Subscribable на, допустим, IntenseSubscribable — то же самое поведение, но с другой механикой.

В Event и Day уже происходят механики, жёстко привязанные к особенностям Subscribable. Например, подтверждение сделано через прослушивание сообщений. А в IntenseSubscribable пользователь нажимает кнопку, при этом никакое сообщение не отправляется.

Кроме того различные *able типа Subscribable обычно описываются интерфейсами, а не наследованием.

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

Это ты в ловушке, потому что не умеешь или делаешь вид, что не умеешь в ООП с наследованием.

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

IMHO главное [до сих пор идёт речь о количестве кода] определяется не разумом определённого человека, а целями проекта и эффективностью программирования.

Не определённого, но я и не говорил про определённого.

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

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

GUI, 3D графика, математика и т.п. В такого рода проектах implementation inheritance может сокращать количество кода в разы!

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

Ты апеллируешь к субъективным предпочтениям, а я - к объективным метрикам.

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

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

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

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

Где?

подменяешь технические аргументы своими философскими

Они не полностью мои. И разница между техникой и философией в нашем контексте несущественна. Эпистемология — наука, посвящённая поиску правильных методов получения и подтверждения знаний. Строительный блок ООП в современном понимании — понятие об абстракции, дошедшее до нас со времён Древней Греции. Да и большинство моих аргументов вполне соответствуют современным представлениям об ООП: is-a, has-a, отношения между абстракциями — это всё я взял не из философии.

не учитываешь специфику разных доменов

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

ты догматически против наследования

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

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

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

Мне кажется, что ты просто пытаешься рационализировать свою неопытность в ООП-дизайне.

Так субъективные предпочтения или рационализация?

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

Наследование реализации, в свою очередь, расширяет понятие возможностью переиспользования реализации (разница между private и protected не столь важна).

Почему по твоему важно является ли метод реализацией, а не то, какой доступ ему назначен? И для чего важно?

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

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

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

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

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

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

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

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

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

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

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

[Множественное наследование не] считается хорошей практикой в отличие от немножественного наследования.

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

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

Разве нельзя было унаследовать Event и Day от IntenseSubscribable, а IntenseSubscribable от Subscribable ?

Иногда можно, иногда нет. Что если Subscribable — это уведомление на почту/календарь, а IntenseSubscribable — в какой-нибудь модный мессенджер?

Надо было сразу назвать этот пример, но упустил, сорри. Именно этот пример я имел ввиду здесь:

Ты не можешь легко заменить Subscribable на, допустим, IntenseSubscribable — то же самое поведение, но с другой механикой.

В Event и Day уже происходят механики, жёстко привязанные к особенностям Subscribable. Например, подтверждение сделано через прослушивание сообщений. А в IntenseSubscribable пользователь нажимает кнопку, при этом никакое сообщение не отправляется.

Кроме того различные *able типа Subscribable обычно описываются интерфейсами, а не наследованием.

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

Это ты в ловушке, потому что не умеешь или делаешь вид, что не умеешь в ООП с наследованием.

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

IMHO главное [до сих пор идёт речь о количестве кода] определяется не разумом определённого человека, а целями проекта и эффективностью программирования.

Не определённого, но я и не говорил про определённого.

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

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

GUI, 3D графика, математика и т.п. В такого рода проектах implementation inheritance может сокращать количество кода в разы!

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

Ты апеллируешь к субъективным предпочтениям, а я - к объективным метрикам.

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

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

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

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

Где?

подменяешь технические аргументы своими философскими

Они не полностью мои. И разница между техникой и философией в нашем контексте несущественна. Эпистемология — наука, посвящённая поиску правильных методов получения и подтверждения знаний. Строительный блок ООП в современном понимании — понятие об абстракции, дошедшее до нас со времён Древней Греции. Да и большинство моих аргументов вполне соответствуют современным представлениям об ООП: is-a, has-a, отношения между абстракциями — это всё я взял не из философии.

не учитываешь специфику разных доменов

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

ты догматически против наследования

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

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

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

Мне кажется, что ты просто пытаешься рационализировать свою неопытность в ООП-дизайне.

Так субъективные предпочтения или рационализация?

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

Наследование реализации, в свою очередь, расширяет понятие возможностью переиспользования реализации (разница между private и protected не столь важна).

Почему по твоему важно является ли метод реализацией, а не то, какой доступ ему назначен? И для чего важно?

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

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

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

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

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

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

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

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

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

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

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

[Множественное наследование не] считается хорошей практикой в отличие от немножественного наследования.

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

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

Разве нельзя было унаследовать Event и Day от IntenseSubscribable, а IntenseSubscribable от Subscribable ?

Иногда можно, иногда нет. Что если Subscribable — это уведомление на почту/календарь, а IntenseSubscribable — в какой-нибудь модный мессенджер?

Надо было сразу назвать этот пример, но упустил, сорри. Именно этот пример я имел ввиду здесь:

Ты не можешь легко заменить Subscribable на, допустим, IntenseSubscribable — то же самое поведение, но с другой механикой.

В Event и Day уже происходят механики, жёстко привязанные к особенностям Subscribable. Например, подтверждение сделано через прослушивание сообщений. А в IntenseSubscribable пользователь нажимает кнопку, при этом никакое сообщение не отправляется.

Кроме того различные *able типа Subscribable обычно описываются интерфейсами, а не наследованием.

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

Это ты в ловушке, потому что не умеешь или делаешь вид, что не умеешь в ООП с наследованием.

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

IMHO главное [до сих пор идёт речь о количестве кода] определяется не разумом определённого человека, а целями проекта и эффективностью программирования.

Не определённого, но я и не говорил про определённого.

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

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

GUI, 3D графика, математика и т.п. В такого рода проектах implementation inheritance может сокращать количество кода в разы!

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

Ты апеллируешь к субъективным предпочтениям, а я - к объективным метрикам.

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

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

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

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

Где?

подменяешь технические аргументы своими философскими

Они не мои. И разница между техникой и философией в нашем контексте несущественна. Эпистемология — наука, посвящённая поиску правильных методов получения и подтверждения знаний. Строительный блок ООП в современном понимании — понятие об абстракции, дошедшее до нас со времён Древней Греции. Да и большинство моих аргументов вполне соответствуют современным представлениям об ООП: is-a, has-a, отношения между абстракциями — это всё я взял не из философии.

не учитываешь специфику разных доменов

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

ты догматически против наследования

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

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

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

Мне кажется, что ты просто пытаешься рационализировать свою неопытность в ООП-дизайне.

Так субъективные предпочтения или рационализация?

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

Наследование реализации, в свою очередь, расширяет понятие возможностью переиспользования реализации (разница между private и protected не столь важна).

Почему по твоему важно является ли метод реализацией, а не то, какой доступ ему назначен? И для чего важно?

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

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

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

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

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

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

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

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

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

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

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

[Множественное наследование не] считается хорошей практикой в отличие от немножественного наследования.

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

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

Разве нельзя было унаследовать Event и Day от IntenseSubscribable, а IntenseSubscribable от Subscribable ?

Иногда можно, иногда нет. Что если Subscribable — это уведомление на почту/календарь, а IntenseSubscribable — в какой-нибудь модный мессенджер?

Надо было сразу назвать этот пример, но упустил, сорри. Именно этот пример я имел ввиду здесь:

Ты не можешь легко заменить Subscribable на, допустим, IntenseSubscribable — то же самое поведение, но с другой механикой.

В Event и Day уже происходят механики, жёстко привязанные к особенностям Subscribable. Например, подтверждение сделано через прослушивание сообщений. А в IntenseSubscribable пользователь нажимает кнопку, при этом никакое сообщение не отправляется.

Кроме того различные *able типа Subscribable обычно описываются интерфейсами, а не наследованием.

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

Это ты в ловушке, потому что не умеешь или делаешь вид, что не умеешь в ООП с наследованием.

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

IMHO главное [до сих пор идёт речь о количестве кода] определяется не разумом определённого человека, а целями проекта и эффективностью программирования.

Не определённого, но я и не говорил про определённого.

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

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

GUI, 3D графика, математика и т.п. В такого рода проектах implementation inheritance может сокращать количество кода в разы!

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

Ты апеллируешь к субъективным предпочтениям, а я - к объективным метрикам.

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

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

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

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

Где?

подменяешь технические аргументы своими философскими

Они не мои. И разница между техникой и философией в нашем контексте несущественна. Эпистемология — наука, посвящённая поиску правильных методов получения и подтверждения знаний. Строительный блок ООП в современном понимании — понятие об абстракции, дошедшее до нас со времён Древней Греции. Да и большинство моих аргументов вполне соответствуют современным представлениям об ООП: is-a, has-a, отношения между абстракциями — это всё я взял не из философии.

не учитываешь специфику разных доменов

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

ты догматически против наследования

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

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

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

Мне кажется, что ты просто пытаешься рационализировать свою неопытность в ООП-дизайне.

Так субъективные предпочтения или рационализация?

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

Наследование реализации, в свою очередь, расширяет понятие возможностью переиспользования реализации (разница между private и protected не столь важна).

Почему по твоему важно является ли метод реализацией, а не то, какой доступ ему назначен? И для чего важно?

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

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

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

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

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

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

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

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

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

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

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

[Множественное наследование не] считается хорошей практикой в отличие от немножественного наследования.

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

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

Разве нельзя было унаследовать Event и Day от IntenseSubscribable, а IntenseSubscribable от Subscribable ?

Иногда можно, иногда нет. Что если Subscribable — это уведомление на почту/календарь, а IntenseSubscribable — в какой-нибудь модный мессенджер?

Надо было сразу назвать этот пример, но упустил, сорри. Именно этот пример я имел ввиду здесь:

Ты не можешь легко заменить Subscribable на, допустим, IntenseSubscribable — то же самое поведение, но с другой механикой.

В Event и Day уже происходят механики, жёстко привязанные к особенностям Subscribable. Например, подтверждение сделано через прослушивание сообщений. А в IntenseSubscribable пользователь нажимает кнопку, при этом никакое сообщение не отправляется.

Кроме того различные *able типа Subscribable обычно описываются интерфейсами, а не наследованием.

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

Это ты в ловушке, потому что не умеешь или делаешь вид, что не умеешь в ООП с наследованием.

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

IMHO главное [до сих пор идёт речь о количестве кода] определяется не разумом определённого человека, а целями проекта и эффективностью программирования.

Не определённого, но я и не говорил про определённого.

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

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

GUI, 3D графика, математика и т.п. В такого рода проектах implementation inheritance может сокращать количество кода в разы!

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

Ты апеллируешь к субъективным предпочтениям, а я - к объективным метрикам.

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

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

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

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

Где?

подменяешь технические аргументы своими философскими

Они не мои. И разница между техникой и философией в нашем контексте несущественна. Эпистемология — наука, посвящённая поиску правильных методов получения и подтверждения знаний. Строительный блок ООП в современном понимании — понятие об абстракции, дошедшее до нас со времён Древней Греции. Да и большинство моих аргументов вполне соответствуют современным представлениям об ООП: is-a, has-a, отношения между абстракциями — это всё я взял не из философии.

не учитываешь специфику разных доменов

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

ты догматически против наследования

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

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

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

Мне кажется, что ты просто пытаешься рационализировать свою неопытность в ООП-дизайне.

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

Наследование реализации, в свою очередь, расширяет понятие возможностью переиспользования реализации (разница между private и protected не столь важна).

Почему по твоему важно является ли метод реализацией, а не то, какой доступ ему назначен? И для чего важно?

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

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

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

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

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

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

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

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

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

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

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

[Множественное наследование не] считается хорошей практикой в отличие от немножественного наследования.

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

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

Разве нельзя было унаследовать Event и Day от IntenseSubscribable, а IntenseSubscribable от Subscribable ?

Иногда можно, иногда нет. Что если Subscribable — это уведомление на почту/календарь, а IntenseSubscribable — в какой-нибудь модный мессенджер?

Надо было сразу назвать этот пример, но упустил, сорри. Именно этот пример я имел ввиду здесь:

Ты не можешь легко заменить Subscribable на, допустим, IntenseSubscribable — то же самое поведение, но с другой механикой.

В Event и Day уже происходят механики, жёстко привязанные к особенностям Subscribable. Например, подтверждение сделано через прослушивание сообщений. А в IntenseSubscribable пользователь нажимает кнопку, при этом никакое сообщение не отправляется.

Кроме того различные *able типа Subscribable обычно описываются интерфейсами, а не наследованием.

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

Это ты в ловушке, потому что не умеешь или делаешь вид, что не умеешь в ООП с наследованием.

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

IMHO главное [до сих пор идёт речь о количестве кода] определяется не разумом определённого человека, а целями проекта и эффективностью программирования.

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

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

GUI, 3D графика, математика и т.п. В такого рода проектах implementation inheritance может сокращать количество кода в разы!

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

Ты апеллируешь к субъективным предпочтениям, а я - к объективным метрикам.

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

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

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

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

Где?

подменяешь технические аргументы своими философскими

Они не мои. И разница между техникой и философией в нашем контексте несущественна. Эпистемология — наука, посвящённая поиску правильных методов получения и подтверждения знаний. Строительный блок ООП в современном понимании — понятие об абстракции, дошедшее до нас со времён Древней Греции. Да и большинство моих аргументов вполне соответствуют современным представлениям об ООП: is-a, has-a, отношения между абстракциями — это всё я взял не из философии.

не учитываешь специфику разных доменов

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

ты догматически против наследования

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

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

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

Мне кажется, что ты просто пытаешься рационализировать свою неопытность в ООП-дизайне.

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

Наследование реализации, в свою очередь, расширяет понятие возможностью переиспользования реализации (разница между private и protected не столь важна).

Почему по твоему важно является ли метод реализацией, а не то, какой доступ ему назначен? И для чего важно?

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

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

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

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

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

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

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

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

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

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

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

[Множественное наследование не] считается хорошей практикой в отличие от немножественного наследования.

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

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

Разве нельзя было унаследовать Event и Day от IntenseSubscribable, а IntenseSubscribable от Subscribable ?

Иногда можно, иногда нет. Что если Subscribable — это уведомление на почту/календарь, а IntenseSubscribable — в какой-нибудь модный мессенджер?

Надо было сразу назвать этот пример, но упустил, сорри. Именно этот пример я имел ввиду здесь:

Ты не можешь легко заменить Subscribable на, допустим, IntenseSubscribable — то же самое поведение, но с другой механикой.

В Subscribable уже происходит привязка ко всяким специфичным для почты/календаря механикам. Например, подтверждение сделано через прослушивание сообщений. А в IntenseSubscribable пользователь нажимает кнопку, при этом никакое сообщение не отправляется.

Кроме того различные *able типа Subscribable обычно описываются интерфейсами, а не наследованием.

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

Это ты в ловушке, потому что не умеешь или делаешь вид, что не умеешь в ООП с наследованием.

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

IMHO главное [до сих пор идёт речь о количестве кода] определяется не разумом определённого человека, а целями проекта и эффективностью программирования.

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

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

GUI, 3D графика, математика и т.п. В такого рода проектах implementation inheritance может сокращать количество кода в разы!

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

Ты апеллируешь к субъективным предпочтениям, а я - к объективным метрикам.

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

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

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

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

Где?

подменяешь технические аргументы своими философскими

Они не мои. И разница между техникой и философией в нашем контексте несущественна. Эпистемология — наука, посвящённая поиску правильных методов получения и подтверждения знаний. Строительный блок ООП в современном понимании — понятие об абстракции, дошедшее до нас со времён Древней Греции. Да и большинство моих аргументов вполне соответствуют современным представлениям об ООП: is-a, has-a, отношения между абстракциями — это всё я взял не из философии.

не учитываешь специфику разных доменов

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

ты догматически против наследования

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

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

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

Мне кажется, что ты просто пытаешься рационализировать свою неопытность в ООП-дизайне.

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