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

Сокращает ли наследование реализации код? Возможно.

Точно сокращает и очень значительно, потому что это implementation inheritance.

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

Как и процедуры.

Вовсе не как процедуры. Процедуры при правильном использовании конечно обеспечивают DRY, но до наследования сильно не дотягивают, потому что наследование происходит автоматически, а при использовании композиции и DRY процедур ты вынужден прописывать их вызовы вручную. Это увеличивает количество точек вызова, а значит, и вероятность ошибок - забыть вызвать, перепутать параметры и т.д. Кроме того, если структура программы сложная, поддерживать корректные вызовы процедур становится труднее.

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

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

Golang разработчиков всего около 1% на рынке вакансий? Согласились? А их кто-то спрашивал? LOL Большинство остальных вакансий программистов подразумевают использование классических ООП языков с наследованием? Даже Питонистов более чем на порядок больше, а Питон используется в т.ч. и в DevOps, btw.

Сокращает ли наследование реализации код? Возможно.

Точно сокращает и очень значительно, потому что это implementation inheritance.

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

Как и процедуры.

Вовсе не как процедуры. Процедуры при правильном использовании конечно обеспечивают DRY, но до наследования сильно не дотягивают, потому что наследование происходит автоматически, а при использовании композиции и DRY процедур ты вынужден прописывать их вызовы вручную. Это увеличивает количество точек вызова, а значит, и вероятность ошибок - забыть вызвать, перепутать параметры и т.д. Кроме того, если структура программы сложная, поддерживать корректные вызовы процедур становится труднее.

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

Golang разработчиков всего около 1% на рынке вакансий? Согласились? А их кто-то спрашивал? LOL Большинство остальных вакансий программистов подразумевают использование классических ООП языков с наследованием? Даже Питонистов более чем на порядок больше, а Питон используется в т.ч. и в DevOps, btw.

Сокращает ли наследование реализации код? Возможно.

Точно сокращает и очень значительно, потому что это implementation inheritance.

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

Как и процедуры.

Вовсе не как процедуры. Процедуры при правильном использовании конечно обеспечивают DRY, но до наследования сильно не дотягивают, потому что наследование происходит автоматически, а при использовании композиции и DRY процедур ты вынужден прописывать все вызовы вручную. Это увеличивает количество точек вызова, а значит, и вероятность ошибок - забыть вызвать, перепутать параметры и т.д. Кроме того, если структура программы сложная, поддерживать корректные вызовы процедур становится труднее.

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

Golang разработчиков всего около 1% на рынке вакансий? Согласились? А их кто-то спрашивал? LOL Большинство остальных вакансий программистов подразумевают использование классических ООП языков с наследованием? Даже Питонистов более чем на порядок больше, а Питон используется в т.ч. и в DevOps, btw.