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

При том, что реализация — это private или protected. Не важна потому что если сделать свойство или метод protected, то он не перестанет от этого быть реализацией.

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

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

Инкапсуляция не то чтобы нарушена, её скорее нет на данном уровне.

private - скрыто от всех, включая наследников - полная инкапсуляция

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

public - доступно всем - не инкапсулировано

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

Если пришлось бы менять родительский класс, то это неправильная попыткая использования наследования?

Изменение кода — это волшебная палочка, которая позволяет решить любую проблему)

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

Конечно не подходит, иначе всё было бы прекрасно и все были бы счастливы.

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

А в C++ так можно делать.

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

Но в более глубоком смысле он подходит. Вот что должно было меня остановить от наследования Event и Day от Subscribable? Наследование — это отношение между двумя абстракциями в контексте, ограниченном is-a. Event is subscribable, day is subscribable. Потом потребовалось—допустим, проект развивается—добавить IntenseSubscribable.

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

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

Мы в ловушке.

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

Главное для чего?

Для разума человека. Но об этом мне не хочется дискутировать.

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

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

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

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

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

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

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

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

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

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

При том, что реализация — это private или protected. Не важна потому что если сделать свойство или метод protected, то он не перестанет от этого быть реализацией.

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

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

Инкапсуляция не то чтобы нарушена, её скорее нет на данном уровне.

private - скрыто от всех, включая наследников - полная инкапсуляция

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

public - доступно всем - не инкапсулировано

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

Если пришлось бы менять родительский класс, то это неправильная попыткая использования наследования?

Изменение кода — это волшебная палочка, которая позволяет решить любую проблему)

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

Конечно не подходит, иначе всё было бы прекрасно и все были бы счастливы.

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

А в C++ так можно делать.

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

Но в более глубоком смысле он подходит. Вот что должно было меня остановить от наследования Event и Day от Subscribable? Наследование — это отношение между двумя абстракциями в контексте, ограниченном is-a. Event is subscribable, day is subscribable. Потом потребовалось—допустим, проект развивается—добавить IntenseSubscribable.

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

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

Мы в ловушке.

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

Главное для чего?

Для разума человека. Но об этом мне не хочется дискутировать.

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

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

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

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

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

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

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

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

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

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

При том, что реализация — это private или protected. Не важна потому что если сделать свойство или метод protected, то он не перестанет от этого быть реализацией.

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

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

Инкапсуляция не то чтобы нарушена, её скорее нет на данном уровне.

private - скрыто от всех, включая наследников - полная инкапсуляция

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

public - доступно всем - не инкапсулировано

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

Если пришлось бы менять родительский класс, то это неправильная попыткая использования наследования?

Изменение кода — это волшебная палочка, которая позволяет решить любую проблему)

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

Конечно не подходит, иначе всё было бы прекрасно и все были бы счастливы.

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

А в C++ так можно делать.

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

Но в более глубоком смысле он подходит. Вот что должно было меня остановить от наследования Event и Day от Subscribable? Наследование — это отношение между двумя абстракциями в контексте, ограниченном is-a. Event is subscribable, day is subscribable. Потом потребовалось—допустим, проект развивается—добавить IntenseSubscribable.

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

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

Мы в ловушке.

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

Главное для чего?

Для разума человека. Но об этом мне не хочется дискутировать.

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

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

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

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

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

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

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

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

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

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

При том, что реализация — это private или protected. Не важна потому что если сделать свойство или метод protected, то он не перестанет от этого быть реализацией.

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

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

Инкапсуляция не то чтобы нарушена, её скорее нет на данном уровне.

private - скрыто от всех, включая наследников - полная инкапсуляция

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

public - доступно всем - не инкапсулировано

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

Если пришлось бы менять родительский класс, то это неправильная попыткая использования наследования?

Изменение кода — это волшебная палочка, которая позволяет решить любую проблему)

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

Конечно не подходит, иначе всё было бы прекрасно и все были бы счастливы.

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

А в C++ так можно делать.

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

Но в более глубоком смысле он подходит. Вот что должно было меня остановить от наследования Event и Day от Subscribable? Наследование — это отношение между двумя абстракциями в контексте, ограниченном is-a. Event is subscribable, day is subscribable. Потом потребовалось—допустим, проект развивается—добавить IntenseSubscribable.

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

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

Мы в ловушке.

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

Главное для чего?

Для разума человека. Но об этом мне не хочется дискутировать.

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

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

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

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

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

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

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