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

Давай приземлим понятия к земле.

Что это значит? Упрощение?

В целом, да, но в особенности это обозначает хорошо подобранные примеры.

Абстракция — это способ ментально отделить и использовать в свою пользу какой-то аспект реальности,

Почему обязательно в свою пользу? Абстракции бывают и вредными?

Бывают. Ещё они бывают лишены реальности. Я назвал определение, которое считаю важным в данном конкретном контексте.

аспект реальности, который не может существовать отдельно.

Отдельно от чего?

Отдельно от того, от чего он отделён. Например, «длина» сама по себе не существует отдельно от спички или палки. Или «файл» отдельно от того, куда в конечном счёте попадают данные.

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

Причём тут это? И почему разница неважна?

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

Понятия должны быть основаны на существенной (или фундаментальной) характеристике.

Понятия, которые ты «приземляешь» (c)?

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

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

…

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

Расшифруй своё сообщение. Какое отношение имеет абстрактность к возможности наследования того или иного свойства или метода?

Отношение наследования к абстракности таково, что наследование — это отношение между двумя абстракциями.

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

По твоему для выявления общего свойства нужна абстрактность такого свойства, а не его наследуемость?

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

Это особенно удобно, если в будущем потребуется изменить общую логику: достаточно внести изменения только в одном месте - в базовом классе.

Когда у вас в коде будет N потомков которые все ещё ориентируются на старое поведение и M потомков которые ориентируются на новое

Разве нельзя для нового поведения сделать дополнительный уровень наследования вместо внесения изменений в оригинальный родительский класс ?

Противоречивые параграфы выделил полужирным.

Какой именно принцип инкапсуляции был нарушен с твоей точки зрения?

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

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

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

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

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

Но нет, я имел ввиду, что нужно сохранить родительский класс (кто-то может его использовать), а для текущего класса нужно изменить родительский класс. Это как раз сложно сделать, потому что нет инкапсуляции родительского класса — мы буквально влезли в кишки реализации.

Множественное наследование не приветствуется ни в Java, ни в C#.

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

Твой пример просто не подходит для наследования, только и всего.

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

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

ООП с наследованием намного сильнее сокращает код … я уже устал объяснять.

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

Я говорил о том, что [количества кода] не самое главное.

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

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

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

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

Давай приземлим понятия к земле.

Что это значит? Упрощение?

В целом, да, но в особенности это обозначает хорошо подобранные примеры.

Абстракция — это способ ментально отделить и использовать в свою пользу какой-то аспект реальности,

Почему обязательно в свою пользу? Абстракции бывают и вредными?

Бывают. Ещё они бывают лишены реальности. Я назвал определение, которое считаю важным в данном конкретном контексте.

аспект реальности, который не может существовать отдельно.

Отдельно от чего?

Отдельно от того, от чего он отделён. Например, «длина» сама по себе не существует отдельно от спички или палки. Или «файл» отдельно от того, куда в конечном счёте попадают данные.

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

Причём тут это? И почему разница неважна?

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

Понятия должны быть основаны на существенной (или фундаментальной) характеристике.

Понятия, которые ты «приземляешь» (c)?

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

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

…

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

Расшифруй своё сообщение. Какое отношение имеет абстрактность к возможности наследования того или иного свойства или метода?

Отношение наследования к абстракности таково, что наследование — это отношение между двумя абстракциями.

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

По твоему для выявления общего свойства нужна абстрактность такого свойства, а не его наследуемость?

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

Это особенно удобно, если в будущем потребуется изменить общую логику: достаточно внести изменения только в одном месте - в базовом классе.

Когда у вас в коде будет N потомков которые все ещё ориентируются на старое поведение и M потомков которые ориентируются на новое

Разве нельзя для нового поведения сделать дополнительный уровень наследования вместо внесения изменений в оригинальный родительский класс ?

Противоречивые параграфы выделил полужирным.

Какой именно принцип инкапсуляции был нарушен с твоей точки зрения?

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

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

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

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

Но нет, я имел ввиду, что нужно сохранить родительский класс (кто-то может его использовать), а для текущего класса нужно изменить родительский класс. Это как раз сложно сделать, потому что нет инкапсуляции родительского класса — мы буквально влезли в кишки реализации.

Множественное наследование не приветствуется ни в Java, ни в C#.

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

Твой пример просто не подходит для наследования, только и всего.

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

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

ООП с наследованием намного сильнее сокращает код … я уже устал объяснять.

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

Я говорил о том, что [количества кода] не самое главное.

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

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

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

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

Давай приземлим понятия к земле.

Что это значит? Упрощение?

В целом, да, но в особенности это обозначает хорошо подобранные примеры.

Абстракция — это способ ментально отделить и использовать в свою пользу какой-то аспект реальности,

Почему обязательно в свою пользу? Абстракции бывают и вредными?

Бывают. Ещё они бывают лишены реальности. Я назвал определение, которое считаю важным в данном конкретном контексте.

аспект реальности, который не может существовать отдельно.

Отдельно от чего?

Отдельно от того, от чего он отделён. Например, «длина» сама по себе не существует отдельно от спички или палки. Или «файл» отдельно от того, куда в конечном счёте попадают данные.

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

Причём тут это? И почему разница неважна?

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

Понятия должны быть основаны на существенной (или фундаментальной) характеристике.

Понятия, которые ты «приземляешь» (c)?

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

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

…

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

Расшифруй своё сообщение. Какое отношение имеет абстрактность к возможности наследования того или иного свойства или метода?

Отношение наследования к абстракности таково, что наследование — это отношение между двумя абстракциями.

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

По твоему для выявления общего свойства нужна абстрактность такого свойства, а не его наследуемость?

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

Это особенно удобно, если в будущем потребуется изменить общую логику: достаточно внести изменения только в одном месте - в базовом классе.

Когда у вас в коде будет N потомков которые все ещё ориентируются на старое поведение и M потомков которые ориентируются на новое

Разве нельзя для нового поведения сделать дополнительный уровень наследования вместо внесения изменений в оригинальный родительский класс ?

Противоречивые параграфы выделил полужирным.

Что касается палки о совместимости. Предполагается, что наследование ограничено контекстом is-a, поэтому прям сильно несовместимые изменения не должны появляться.

Какой именно принцип инкапсуляции был нарушен с твоей точки зрения?

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

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

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

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

Но нет, я имел ввиду, что нужно сохранить родительский класс (кто-то может его использовать), а для текущего класса нужно изменить родительский класс. Это как раз сложно сделать, потому что нет инкапсуляции родительского класса — мы буквально влезли в кишки реализации.

Множественное наследование не приветствуется ни в Java, ни в C#.

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

Твой пример просто не подходит для наследования, только и всего.

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

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

ООП с наследованием намного сильнее сокращает код … я уже устал объяснять.

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

Я говорил о том, что [количества кода] не самое главное.

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

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

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

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

Давай приземлим понятия к земле.

Что это значит? Упрощение?

В целом, да, но в особенности это обозначает хорошо подобранные примеры.

Абстракция — это способ ментально отделить и использовать в свою пользу какой-то аспект реальности,

Почему обязательно в свою пользу? Абстракции бывают и вредными?

Бывают. Ещё они бывают лишены реальности. Я назвал определение, которое считаю важным в данном конкретном контексте.

аспект реальности, который не может существовать отдельно.

Отдельно от чего?

Отдельно от того, от чего он отделён. Например, «длина» сама по себе не существует отдельно от спички или палки. Или «файл» отдельно от того, куда в конечном счёте попадают данные.

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

Причём тут это? И почему разница неважна?

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

Понятия должны быть основаны на существенной (или фундаментальной) характеристике.

Понятия, которые ты «приземляешь» (c)?

Человек — это живой организм с двумя глазами. Вот пример понятия без существенной характеристики. Именно так выглядит твоё помешательство на наследовании как способе сократить число кода.

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

…

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

Расшифруй своё сообщение. Какое отношение имеет абстрактность к возможности наследования того или иного свойства или метода?

Отношение наследования к абстракности таково, что наследование — это отношение между двумя абстракциями.

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

По твоему для выявления общего свойства нужна абстрактность такого свойства, а не его наследуемость?

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

Это особенно удобно, если в будущем потребуется изменить общую логику: достаточно внести изменения только в одном месте - в базовом классе.

Когда у вас в коде будет N потомков которые все ещё ориентируются на старое поведение и M потомков которые ориентируются на новое

Разве нельзя для нового поведения сделать дополнительный уровень наследования вместо внесения изменений в оригинальный родительский класс ?

Противоречивые параграфы выделил полужирным.

Что касается палки о совместимости. Предполагается, что наследование ограничено контекстом is-a, поэтому прям сильно несовместимые изменения не должны появляться.

Какой именно принцип инкапсуляции был нарушен с твоей точки зрения?

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

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

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

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

Но нет, я имел ввиду, что нужно сохранить родительский класс (кто-то может его использовать), а для текущего класса нужно изменить родительский класс. Это как раз сложно сделать, потому что нет инкапсуляции родительского класса — мы буквально влезли в кишки реализации.

Множественное наследование не приветствуется ни в Java, ни в C#.

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

Твой пример просто не подходит для наследования, только и всего.

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

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

ООП с наследованием намного сильнее сокращает код … я уже устал объяснять.

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

Я говорил о том, что [количества кода] не самое главное.

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

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

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

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

Давай приземлим понятия к земле.

Что это значит? Упрощение?

В целом, да, но в особенности это обозначает хорошо подобранные примеры.

Абстракция — это способ ментально отделить и использовать в свою пользу какой-то аспект реальности,

Почему обязательно в свою пользу? Абстракции бывают и вредными?

Бывают. Ещё они бывают лишены реальности. Я назвал определение, которое считаю важным в данном конкретном контексте.

который не может существовать отдельно.

Отдельно от чего?

Отдельно от того, от чего он отделён. Например, «длина» сама по себе не существует отдельно от спички или палки. Или «файл» отдельно от того, куда в конечном счёте попадают данные.

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

Причём тут это? И почему разница неважна?

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

Понятия должны быть основаны на существенной (или фундаментальной) характеристике.

Понятия, которые ты «приземляешь» (c)?

Человек — это живой организм с двумя глазами. Вот пример понятия без существенной характеристики. Именно так выглядит твоё помешательство на наследовании как способе сократить число кода.

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

…

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

Расшифруй своё сообщение. Какое отношение имеет абстрактность к возможности наследования того или иного свойства или метода?

Отношение наследования к абстракности таково, что наследование — это отношение между двумя абстракциями.

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

По твоему для выявления общего свойства нужна абстрактность такого свойства, а не его наследуемость?

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

Это особенно удобно, если в будущем потребуется изменить общую логику: достаточно внести изменения только в одном месте - в базовом классе.

Когда у вас в коде будет N потомков которые все ещё ориентируются на старое поведение и M потомков которые ориентируются на новое

Разве нельзя для нового поведения сделать дополнительный уровень наследования вместо внесения изменений в оригинальный родительский класс ?

Противоречивые параграфы выделил полужирным.

Что касается палки о совместимости. Предполагается, что наследование ограничено контекстом is-a, поэтому прям сильно несовместимые изменения не должны появляться.

Какой именно принцип инкапсуляции был нарушен с твоей точки зрения?

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

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

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

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

Но нет, я имел ввиду, что нужно сохранить родительский класс (кто-то может его использовать), а для текущего класса нужно изменить родительский класс. Это как раз сложно сделать, потому что нет инкапсуляции родительского класса — мы буквально влезли в кишки реализации.

Множественное наследование не приветствуется ни в Java, ни в C#.

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

Твой пример просто не подходит для наследования, только и всего.

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

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

ООП с наследованием намного сильнее сокращает код … я уже устал объяснять.

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

Я говорил о том, что [количества кода] не самое главное.

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

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

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

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

Лол

Давай приземлим понятия к земле.

Что это значит? Упрощение?

В целом, да, но в особенности это обозначает хорошо подобранные примеры.

Абстракция — это способ ментально отделить и использовать в свою пользу какой-то аспект реальности,

Почему обязательно в свою пользу? Абстракции бывают и вредными?

Бывают. Ещё они бывают лишены реальности. Я назвал определение, которое считаю важным в данном конкретном контексте.

который не может существовать отдельно.

Отдельно от чего?

Отдельно от того, от чего он отделён. Например, «длина» сама по себе не существует отдельно от спички или палки. Или «файл» отдельно от того, куда в конечном счёте попадают данные.

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

Причём тут это? И почему разница неважна?

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

Понятия должны быть основаны на существенной (или фундаментальной) характеристике.

Понятия, которые ты «приземляешь» (c)?

Человек — это живой организм с двумя глазами. Вот пример понятия без существенной характеристики. Именно так выглядит твоё помешательство на наследовании как способе сократить число кода.

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

…

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

Расшифруй своё сообщение. Какое отношение имеет абстрактность к возможности наследования того или иного свойства или метода?

Отношение наследования к абстракности таково, что наследование — это отношение между двумя абстракциями.

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

По твоему для выявления общего свойства нужна абстрактность такого свойства, а не его наследуемость?

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

Это особенно удобно, если в будущем потребуется изменить общую логику: достаточно внести изменения только в одном месте - в базовом классе.

Когда у вас в коде будет N потомков которые все ещё ориентируются на старое поведение и M потомков которые ориентируются на новое

Разве нельзя для нового поведения сделать дополнительный уровень наследования вместо внесения изменений в оригинальный родительский класс ?

Противоречивые параграфы выделил полужирным.

Что касается палки о совместимости. Предполагается, что наследование ограничено контекстом is-a, поэтому прям сильно несовместимые изменения не должны появляться.

Какой именно принцип инкапсуляции был нарушен с твоей точки зрения?

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

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

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

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

Но нет, я имел ввиду, что нужно сохранить родительский класс (кто-то может его использовать), а для текущего класса нужно изменить родительский класс. Это как раз сложно сделать, потому что нет инкапсуляции родительского класса — мы буквально влезли в кишки реализации.

Множественное наследование не приветствуется ни в Java, ни в C#.

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

Твой пример просто не подходит для наследования, только и всего.

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

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

ООП с наследованием намного сильнее сокращает код … я уже устал объяснять.

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

Я говорил о том, что [количества кода] не самое главное.

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

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

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

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