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

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

Абсолютнейшая ЛОЖЬ !!!

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

Абстракция — это способ ментально отделить и использовать в свою пользу какой-то аспект реальности, который не может существовать отдельно. Именно благодаря абстракциям пользоваться и программировать компьютеры легко. Ты можешь просто делать write, при этом не уточняя, что под капотом происходит передача данных по сети, запись через NVMe или отправка данных в виртуалку.

Наследование — это способ установления отношения вида is-a между несколькими абстракциями. «Машина имеет двигатель» — это has-a, тогда как «собака есть животное» — это is-a. Наследование реализации, в свою очередь, расширяет понятие возможностью переиспользования реализации (разница между private и protected не столь важна).

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

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

Условный Hello World намного проще и компактнее написать без абстракций.

Hello World, скорее всего, будет написан с помощью стандартных потоков. Это уже абстракция, причём очень широкая и весьма успешная.

А по поводу гибкости я уже приводил ранее решение, так что тоже считаю критику гибкости наследования неверной.

Чет я пропустил это решение. Скинь, пожалуйста, ссылку.

Но я приведу пример того, почему я называю наследование негибким. Есть Event и Day — несколько типов объектов, на которые можно подписаться. Допустим, в нашей системе они настолько родственны, что есть основание создать родительский класс Subscribable и включить в него значительную часть общей реализации.

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

Кроме того, Event и Day важны в нескольких независимых контекстах. Было бы удобно наследовать сразу несколько реализаций. Тогда мы получаем SubscribableAndShareable (или EventDayable) в роли раздутого класса. Или нам нужно множественное наследование с вытекающими проблемами совместимости (нам нужна будет только часть одной из наследуемых реализаций, другая часть будет противоречить дизайну).

Эти две особенности—нарушение инкапсуляции и необходимость выбора иерархии—я и называю негибкими.

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

Понять других людей важнее, чем опровергнуть.

Не велика проблема [прописывать вызовы процедур вручную].

А как ты мерял?

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

Сокращает ли наследование реализации код? Возможно. Как и процедуры. Позволяет ли оно более просто воспринимать программу? С этим сложнее. Я не уверен.

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

В программировании есть вещи намного хуже.

Речь о сокращении объёма кода. Что для этого может быть хуже, чем композиция?

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

Композиция обозначает комбинирование нескольких абстракций в более сложные, при этом не нарушая инкапсуляцию. Опять же, здесь существенная характеристика — абстракции. Выберешь нужные абстракции, будешь их правильно использовать — количество кода сократится.

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

Абсолютнейшая ЛОЖЬ !!!

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

Абстракция — это способ ментально отделить и использовать в свою пользу какой-то аспект реальности, который не может существовать отдельно. Именно благодаря абстракциям пользоваться и программировать компьютеры легко. Ты можешь просто делать write, при этом не уточняя, что под капотом происходит передача данных по сети, запись через NVMe или отправка данных в виртуалку.

Наследование — это способ установления отношения вида is-a между несколькими абстракциями. «Машина имеет двигатель» — это has-a, тогда как «собака есть животное» — это is-a. Наследование реализации, в свою очередь, расширяет понятие возможностью переиспользования реализации (разница между private и protected не столь важна).

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

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

Условный Hello World намного проще и компактнее написать без абстракций.

Hello World, скорее всего, будет написан с помощью стандартных потоков. Это уже абстракция, причём очень широкая и весьма успешная.

А по поводу гибкости я уже приводил ранее решение, так что тоже считаю критику гибкости наследования неверной.

Чет я пропустил это решение. Скинь, пожалуйста, ссылку.

Но я приведу пример того, почему я называю наследование негибким. Есть Event и Day — несколько типов объектов, на которые можно подписаться. Допустим, в нашей системе они настолько родственны, что есть основание создать родительский класс Subscribable и включить в него значительную часть общей реализации.

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

Кроме того, Event и Day важны в нескольких независимых контекстах. Было бы удобно наследовать сразу несколько реализаций. Тогда мы получаем SubscribableAndShareable (или EventDayable) в роли раздутого класса. Или нам нужно множественное наследование с вытекающими проблемами совместимости (нам нужна будет только часть одной из наследуемых реализаций, другая часть будет противоречить дизайну).

Эти две особенности—нарушение инкапсуляции и необходимость выбора иерархии—я и называю негибкими.

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

Понять других людей важнее, чем опровергнуть.

Не велика проблема [прописывать вызовы процедур вручную].

А как ты мерял?

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

Сокращает ли наследование реализации код? Возможно. Как и процедуры. Позволяет ли оно более просто воспринимать программу? С этим сложнее. Я не уверен.

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

В программировании есть вещи намного хуже.

Речь о сокращении объёма кода. Что для этого может быть хуже, чем композиция?

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

Композиция обозначает комбинирование нескольких абстракций в более сложные, при этом не нарушая инкапсуляцию. Опять же, здесь существенная характеристика — абстракции. Выберешь нужные абстракции, будешь их правильно использовать — количество кода сократится.

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

Абсолютнейшая ЛОЖЬ !!!

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

Абстракция — это способ ментально отделить и использовать в свою пользу какой-то аспект реальности, который не может существовать отдельно. Именно благодаря абстракциям пользоваться и программировать компьютеры легко. Ты можешь просто делать write, при этом не уточняя, что под капотом происходит передача данных по сети, запись через NVMe или отправка данных в виртуалку.

Наследование — это способ установления отношения вида is-a между несколькими абстракциями. «Машина имеет двигатель» — это has-a, тогда как «собака есть животное» — это is-a. Наследование реализации, в свою очередь, расширяет понятие возможностью переиспользования реализации (разница между private и protected не столь важна).

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

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

Условный Hello World намного проще и компактнее написать без абстракций.

Hello World, скорее всего, будет написан с помощью стандартных потоков. Это уже абстракция, причём очень широкая и весьма успешная.

А по поводу гибкости я уже приводил ранее решение, так что тоже считаю критику гибкости наследования неверной.

Чет я пропустил это решение. Скинь, пожалуйста, ссылку.

Но я приведу пример того, почему я называю наследование негибким. Есть Event и Day — несколько типов объектов, на которые можно подписаться. Допустим, в нашей системе они настолько родственны, что есть основание создать родительский класс Subscribable и включить в него значительную часть общей реализации.

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

Кроме того, Event и Day важны в нескольких независимых контекстах. Было бы удобно наследовать сразу несколько реализаций. Тогда мы получаем SubscribableAndShareable (или EventDayable) в роли раздутого класса. Или нам нужно множественное наследование с вытекающими проблемами совместимости (нам нужна будет только часть одной из наследуемых реализаций, другая часть будет противоречить дизайну).

Эти две особенности—нарушение инкапсуляции и необходимость выбора иерархии—я и называю негибкими.

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

Понять других людей важнее, чем опровергнуть.

Не велика проблема [прописывать вызовы процедур вручную].

А как ты мерял?

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

Сокращает ли наследование реализации код? Возможно. Как и процедуры. Позволяет ли оно более просто воспринимать программу? С этим сложнее. Я не уверен.

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

В программировании есть вещи намного хуже.

Речь о сокращении объёма кода. Что для этого может быть хуже, чем композиция?

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

Композиция обозначает комбинирование нескольких абстракций в более сложные, при этом не нарушая инкапсуляцию. Опять же, здесь существенная характеристика — абстракции. Выберешь нужные абстракции, будешь их правильно использовать — количество кода сократится.

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

Абсолютнейшая ЛОЖЬ !!!

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

Абстракция — это способ ментально отделить и использовать в свою пользу какой-то аспект реальности, который не может существовать отдельно. Именно благодаря абстракциям пользоваться и программировать компьютеры легко. Ты можешь просто делать write, при этом не уточняя, что под капотом происходит передача данных по сети, запись через NVMe или отправка данных в виртуалку.

Наследование — это способ установления отношения вида is-a между несколькими абстракциями. «Машина имеет двигатель» — это has-a, тогда как «собака есть животное» — это is-a. Наследование реализации, в свою очередь, расширяет понятие возможностью переиспользования реализации (разница между private и protected не столь важна).

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

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

Условный Hello World намного проще и компактнее написать без абстракций.

Hello World, скорее всего, будет написан с помощью стандартных потоков. Это уже абстракция, причём очень широкая и весьма успешная.

А по поводу гибкости я уже приводил ранее решение, так что тоже считаю критику гибкости наследования неверной.

Чет я пропустил это решение. Скинь, пожалуйста, ссылку.

Но я приведу пример того, почему я называю наследование негибким. Есть Event и Day — несколько типов объектов, на которые можно подписаться. Допустим, в нашей системе они настолько родственны, что есть основание создать родительский класс Subscribable и включить в него значительную часть общей реализации.

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

Кроме того, Event и Day важны в нескольких независимых контекстах. Было бы удобно наследовать сразу несколько реализаций. Тогда мы получаем SubscribableAndShareable (или EventDayable) в роли раздутого класса. Или нам нужно множественное наследование с вытекающими проблемами совместимости (нам нужна будет только часть одной из наследуемых реализаций, другая часть будет противоречить дизайну).

Эти две особенности—нарушение инкапсуляции и необходимость выбора иерархии—я и называю негибкими.

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

Понять других людей важнее, чем опровергнуть.

Не велика проблема [прописывать вызовы процедур вручную].

А как ты мерял?

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

Сокращает ли наследование реализации код? Возможно. Как и процедуры. Позволяет ли оно более просто воспринимать программу? С этим сложнее. Я не уверен.

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

В программировании есть вещи намного хуже.

Речь о сокращении объёма кода. Что для этого может быть хуже, чем композиция?

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

Композиция обозначает комбинирование нескольких абстракций в более сложные, при этом не нарушая инкапсуляцию. Опять же, здесь существенная характеристика — абстракции. Выберешь нужные абстракции, будешь их правильно использовать — количество кода сократится.

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

Абсолютнейшая ЛОЖЬ !!!

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

Абстракция — это способ ментально отделить и использовать в свою пользу какой-то аспект реальности, который не может существовать отдельно. Именно благодаря абстракциям пользоваться и программировать компьютеры легко. Ты можешь просто делать write, при этом не осознавая, что под капотом происходит передача данных по сети, запись через NVMe или отправка данных в виртуалку.

Наследование — это способ установления отношения вида is-a между несколькими абстракциями. «Машина имеет двигатель» — это has-a, тогда как «собака есть животное» — это is-a. Наследование реализации, в свою очередь, расширяет понятие возможностью переиспользования реализации (разница между private и protected не столь важна).

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

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

Условный Hello World намного проще и компактнее написать без абстракций.

Hello World, скорее всего, будет написан с помощью стандартных потоков. Это уже абстракция, причём очень широкая и весьма успешная.

А по поводу гибкости я уже приводил ранее решение, так что тоже считаю критику гибкости наследования неверной.

Чет я пропустил это решение. Скинь, пожалуйста, ссылку.

Но я приведу пример того, почему я называю наследование негибким. Есть Event и Day — несколько типов объектов, на которые можно подписаться. Допустим, в нашей системе они настолько родственны, что есть основание создать родительский класс Subscribable и включить в него значительную часть общей реализации.

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

Кроме того, Event и Day важны в нескольких независимых контекстах. Было бы удобно наследовать сразу несколько реализаций. Тогда мы получаем SubscribableAndShareable (или EventDayable) в роли раздутого класса. Или нам нужно множественное наследование с вытекающими проблемами совместимости (нам нужна будет только часть одной из наследуемых реализаций, другая часть будет противоречить дизайну).

Эти две особенности—нарушение инкапсуляции и необходимость выбора иерархии—я и называю негибкими.

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

Понять других людей важнее, чем опровергнуть.

Не велика проблема [прописывать вызовы процедур вручную].

А как ты мерял?

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

Сокращает ли наследование реализации код? Возможно. Как и процедуры. Позволяет ли оно более просто воспринимать программу? С этим сложнее. Я не уверен.

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

В программировании есть вещи намного хуже.

Речь о сокращении объёма кода. Что для этого может быть хуже, чем композиция?

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

Композиция обозначает комбинирование нескольких абстракций в более сложные, при этом не нарушая инкапсуляцию. Опять же, здесь существенная характеристика — абстракции. Выберешь нужные абстракции, будешь их правильно использовать — количество кода сократится.

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

Абсолютнейшая ЛОЖЬ !!!

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

Абстракция — это способ ментально отделить и использовать в свою пользу какой-то аспект реальности, который не может существовать отдельно. Именно благодаря абстракциям пользоваться и программировать компьютеры легко. Ты можешь просто делать write, при этом не осознавая, что под капотом происходит передача данных по сети или запись через NVMe.

Наследование — это способ установления отношения вида is-a между несколькими абстракциями. «Машина имеет двигатель» — это has-a, тогда как «собака есть животное» — это is-a. Наследование реализации, в свою очередь, расширяет понятие возможностью переиспользования реализации (разница между private и protected не столь важна).

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

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

Условный Hello World намного проще и компактнее написать без абстракций.

Hello World, скорее всего, будет написан с помощью стандартных потоков. Это уже абстракция, причём очень широкая и весьма успешная.

А по поводу гибкости я уже приводил ранее решение, так что тоже считаю критику гибкости наследования неверной.

Чет я пропустил это решение. Скинь, пожалуйста, ссылку.

Но я приведу пример того, почему я называю наследование негибким. Есть Event и Day — несколько типов объектов, на которые можно подписаться. Допустим, в нашей системе они настолько родственны, что есть основание создать родительский класс Subscribable и включить в него значительную часть общей реализации.

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

Кроме того, Event и Day важны в нескольких независимых контекстах. Было бы удобно наследовать сразу несколько реализаций. Тогда мы получаем SubscribableAndShareable (или EventDayable) в роли раздутого класса. Или нам нужно множественное наследование с вытекающими проблемами совместимости (нам нужна будет только часть одной из наследуемых реализаций, другая часть будет противоречить дизайну).

Эти две особенности—нарушение инкапсуляции и необходимость выбора иерархии—я и называю негибкими.

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

Понять других людей важнее, чем опровергнуть.

Не велика проблема [прописывать вызовы процедур вручную].

А как ты мерял?

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

Сокращает ли наследование реализации код? Возможно. Как и процедуры. Позволяет ли оно более просто воспринимать программу? С этим сложнее. Я не уверен.

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

В программировании есть вещи намного хуже.

Речь о сокращении объёма кода. Что для этого может быть хуже, чем композиция?

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

Композиция обозначает комбинирование нескольких абстракций в более сложные, при этом не нарушая инкапсуляцию. Опять же, здесь существенная характеристика — абстракции. Выберешь нужные абстракции, будешь их правильно использовать — количество кода сократится.

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

Абсолютнейшая ЛОЖЬ !!!

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

Абстракция — это способ ментально отделить и использовать в свою пользу какой-то аспект реальности, который не может существовать отдельно. Именно благодаря абстракциям пользоваться и программировать компьютеры легко. Ты можешь просто делать write, при этом не осознавая, что под капотом происходит передача данных по сети или запись через NVMe.

Наследование — это способ установления отношения вида is-a между несколькими абстракциями. «Машина имеет двигатель» — это has-a, тогда как «собака есть животное» — это is-a. Наследование реализации, в свою очередь, расширяет понятие возможностью переиспользования реализации (разница между private и protected не столь важна).

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

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

Условный Hello World намного проще и компактнее написать без абстракций.

Hello World, скорее всего, будет написан с помощью стандартных потоков. Это уже абстракция, причём очень широкая и весьма успешная.

А по поводу гибкости я уже приводил ранее решение, так что тоже считаю критику гибкости наследования неверной.

Чет я пропустил это решение. Скинь, пожалуйста, ссылку.

Но я приведу пример того, почему я называю наследование негибким. Есть Event и Day — несколько типов объектов, на которые можно подписаться. Допустим, в нашей системе они настолько родственны, что есть основание создать родительский класс Subscribable и включить в него значительную часть общей реализации.

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

Кроме того, Event и Day важны в нескольких независимых контекстах. Было бы удобно наследовать сразу несколько реализаций. Тогда мы получаем SubscribableAndShareable (или EventDayable) в роли раздутого класса. Или нам нужно множественное наследование с вытекающими проблемами совместимости (нам нужна будет только часть одной из наследуемых реализаций, другая часть будет противоречить дизайну).

Эти две особенности—нарушение инкапсуляции и необходимость выбора иерархии—я и называю негибкими.

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

Понять других людей важнее, чем опровергнуть.

Не велика проблема [прописывать вызовы процедур вручную].

А как ты мерял?

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

Сокращает ли наследование реализации код? Возможно. Как и процедуры. Позволяет ли оно более просто воспринимать программу? С этим сложнее. Я не уверен.

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

В программировании есть вещи намного хуже.

Речь о сокращении объёма кода. Что для этого может быть хуже, чем композиция?

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

Композиция обозначает комбинирование нескольких абстракций в более сложные, при этом не нарушая инкапсуляцию. Опять же, здесь существенная характеристика — абстракции. Выберешь нужные абстракции, будешь их правильно использовать — количество кода сократится.

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

Абсолютнейшая ЛОЖЬ !!!

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

Абстракция — это способ ментально отделить и использовать в свою пользу какой-то аспект реальности, который не может существовать отдельно. Именно благодаря абстракциям пользоваться и программировать компьютеры легко. Ты можешь просто делать write, при этом не осознавая, что пол капотом происходит передача данных по сети или запись через NVMe.

Наследование — это способ установления отношения вида is-a между несколькими абстракциями. «Машина имеет двигатель» — это has-a, тогда как «собака есть животное» — это is-a. Наследование реализации, в свою очередь, расширяет понятие возможностью переиспользования реализации (разница между private и protected не столь важна).

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

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

Условный Hello World намного проще и компактнее написать без абстракций.

Hello World, скорее всего, будет написан с помощью стандартных потоков. Это уже абстракция, причём очень широкая и весьма успешная.

А по поводу гибкости я уже приводил ранее решение, так что тоже считаю критику гибкости наследования неверной.

Чет я пропустил это решение. Скинь, пожалуйста, ссылку.

Но я приведу пример того, почему я называю наследование негибким. Есть Event и Day — несколько типов объектов, на которые можно подписаться. Допустим, в нашей системе они настолько родственны, что есть основание создать родительский класс Subscribable и включить в него значительную часть общей реализации.

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

Кроме того, Event и Day важны в нескольких независимых контекстах. Было бы удобно наследовать сразу несколько реализаций. Тогда мы получаем SubscribableAndShareable (или EventDayable) в роли раздутого класса. Или нам нужно множественное наследование с вытекающими проблемами совместимости (нам нужна будет только часть одной из наследуемых реализаций, другая часть будет противоречить дизайну).

Эти две особенности—нарушение инкапсуляции и необходимость выбора иерархии—я и называю негибкими.

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

Понять других людей важнее, чем опровергнуть.

Не велика проблема [прописывать вызовы процедур вручную].

А как ты мерял?

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

Сокращает ли наследование реализации код? Возможно. Как и процедуры. Позволяет ли оно более просто воспринимать программу? С этим сложнее. Я не уверен.

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

В программировании есть вещи намного хуже.

Речь о сокращении объёма кода. Что для этого может быть хуже, чем композиция?

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

Композиция обозначает комбинирование нескольких абстракций в более сложные, при этом не нарушая инкапсуляцию. Опять же, здесь существенная характеристика — абстракции. Выберешь нужные абстракции, будешь их правильно использовать — количество кода сократится.