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

до создания иерархии классов обычно относительно долго и тщательно опрашиваю по поводу содержимого ТЗ, нередко сам его дорабатываю с подтверждением доработок ТЗ у клиента ессно.

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

Execution of statements at run time tends to jump around in different mixins, making it hard to follow and debug

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

Potential for long compile times

Го создавался с целью быстрых компиляций. Пока что встраивание типов не мешает.

Increased dependencies

It is unclear how to invoke base class constructors, there is a tendency to use the two stage construction pattern

Не понял, к сожалению.

https://legacy.reactjs.org/blog/2016/07/13/mixins-considered-harmful.html

Я далёк от мира JS, так что не могу судить.

О каких «подразделениях» речь?

Subdivision. Есть концепция «животное», а «рыба» — подразделение. Перевёл как смог.

Допустим, у нас есть объект с HTTP-параметрами и в определённом месте работа с ним становится настолько однородной, что появляется возможность создать тип «запрос финансового отчёта». Когда мы создаём подразделения концепций в реальной жизни (животное → рыба), то новые концепции сохраняют существенную характеристику родительской концепции, но она либо сужается, либо дополняется новыми характеристиками. В программировании на ум, конечно, приходит полиморфизм, когда мы можем в любой момент использовать «запрос финансового отчёта» как «HTTP-запрос».

Но это не одно и то же. Для ОО-стиля важен сам факт подразделения, а полиморфизм — это просто возможность символа представлять несколько разных типов. Если нам придётся вместо send(finRequest) использовать send(finRequest.Original), то ничего плохого не случится.

В Го, кстати, описанный пример возможен. Но, в отличие от наследования, мы не можем из кода родительского типа попасть назад в дочерний.

плутать по композиционной лапше (это тот самый «индусский код»?)

Код запутывает не использование композиции, а неправильное использование абстракций

ООП наследование при правильном использовании абстракций сокращает количество кода, а значит и упрощает его откладку и потенциальное количество багов?

Я отвечал на часть про лапшу и имел ввиду любой язык. Другой пример: передача объекта с HTTP-параметрами в тип для запроса пользователя из бд.

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

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

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

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

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

до создания иерархии классов обычно относительно долго и тщательно опрашиваю по поводу содержимого ТЗ, нередко сам его дорабатываю с подтверждением доработок ТЗ у клиента ессно.

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

Execution of statements at run time tends to jump around in different mixins, making it hard to follow and debug

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

Potential for long compile times

Го создавался с целью быстрых компиляций. Пока что встраивание типов не мешает.

Increased dependencies

It is unclear how to invoke base class constructors, there is a tendency to use the two stage construction pattern

Не понял, к сожалению.

https://legacy.reactjs.org/blog/2016/07/13/mixins-considered-harmful.html

Я далёк от мира JS, так что не могу судить.

О каких «подразделениях» речь?

Subdivision. Есть концепция «животное», а «рыба» — подразделение. Перевёл как смог.

Допустим, у нас есть объект с HTTP-параметрами и в определённом месте работа с ним становится настолько однородной, что появляется возможность создать тип «запрос финансового отчёта». Когда мы создаём подразделения концепций в реальной жизни (животное → рыба), то новые концепции сохраняют существенную характеристику родительской концепции, но она либо сужается, либо дополняется новыми характеристиками. В программировании на ум, конечно, приходит полиморфизм, когда мы можем в любой момент использовать «запрос финансового отчёта» как «HTTP-запрос».

Но это не одно и то же. Для ОО-стиля важен сам факт подразделения, а полиморфизм — это просто возможность символа представлять несколько разных типов. Если нам придётся вместо send(finRequest) использовать send(finRequest.Original), то ничего плохого не случится.

В Го, кстати, описанный пример возможен. Но, в отличие от наследования, мы не можем из кода родительского типа попасть назад в дочерний.

плутать по композиционной лапше (это тот самый «индусский код»?)

Код запутывает не использование композиции, а неправильное использование абстракций

ООП наследование при правильном использовании абстракций сокращает количество кода, а значит и упрощает его откладку и потенциальное количество багов?

Я отвечал на часть про лапшу и имел ввиду любой язык. Другой пример: передача объекта с HTTP-параметрами в тип для запроса пользователя из бд.

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

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

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

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

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

до создания иерархии классов обычно относительно долго и тщательно опрашиваю по поводу содержимого ТЗ, нередко сам его дорабатываю с подтверждением доработок ТЗ у клиента ессно.

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

Execution of statements at run time tends to jump around in different mixins, making it hard to follow and debug

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

Potential for long compile times

Го создавался с целью быстрых компиляций. Пока что встраивание типов не мешает.

Increased dependencies

It is unclear how to invoke base class constructors, there is a tendency to use the two stage construction pattern

Не понял, к сожалению.

https://legacy.reactjs.org/blog/2016/07/13/mixins-considered-harmful.html

Я далёк от мира JS, так что не могу судить.

О каких «подразделениях» речь?

Subdivision. Есть концепция «животное», а «рыба» — подразделение. Перевёл как смог.

Допустим, у нас есть объект с HTTP-параметрами и в определённом месте работа с ним становится настолько однородной, что появляется возможность создать тип «запрос финансового отчёта». Когда мы создаём подразделения концепций в реальной жизни (животное → рыба), то новые концепции сохраняют существенную характеристику родительской концепции, но она либо сужается, либо дополняется новыми характеристиками. В программировании на ум, конечно, приходит полиморфизм, когда мы можем в любой момент использовать «запрос финансового отчёта» как «HTTP-запрос».

Но это не одно и то же. Для ОО-стиля важен сам факт подразделения, а полиморфизм — это просто возможность символа представлять несколько разных типов. Если нам придётся вместо send(finRequest) использовать send(finRequest.Original), то ничего плохого не случится.

В Го, кстати, описанный пример возможен. Но, в отличие от наследования, мы не можем из кода родительского типа попасть назад в дочерний.

плутать по композиционной лапше (это тот самый «индусский код»?)

Код запутывает не использование композиции, а неправильное использование абстракций

ООП наследование при правильном использовании абстракций сокращает количество кода, а значит и упрощает его откладку и потенциальное количество багов?

Я отвечал на часть про лапшу и имел ввиду любой язык. Другой пример: передача объекта с HTTP-параметрами в тип для запроса пользователя из бд.

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

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

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

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

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

до создания иерархии классов обычно относительно долго и тщательно опрашиваю по поводу содержимого ТЗ, нередко сам его дорабатываю с подтверждением доработок ТЗ у клиента ессно.

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

Execution of statements at run time tends to jump around in different mixins, making it hard to follow and debug

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

Potential for long compile times

Го создавался с целью быстрых компиляций. Пока что встраивание типов не мешает.

Increased dependencies

It is unclear how to invoke base class constructors, there is a tendency to use the two stage construction pattern

Не понял, к сожалению.

О каких «подразделениях» речь?

Subdivision. Есть концепция «животное», а «рыба» — подразделение. Перевёл как смог.

Допустим, у нас есть объект с HTTP-параметрами и в определённом месте работа с ним становится настолько однородной, что появляется возможность создать тип «запрос финансового отчёта». Когда мы создаём подразделения концепций в реальной жизни (животное → рыба), то новые концепции сохраняют существенную характеристику родительской концепции, но она либо сужается, либо дополняется новыми характеристиками. В программировании на ум, конечно, приходит полиморфизм, когда мы можем в любой момент использовать «запрос финансового отчёта» как «HTTP-запрос».

Но это не одно и то же. Для ОО-стиля важен сам факт подразделения, а полиморфизм — это просто возможность символа представлять несколько разных типов. Если нам придётся вместо send(finRequest) использовать send(finRequest.Original), то ничего плохого не случится.

В Го, кстати, описанный пример возможен. Но, в отличие от наследования, мы не можем из кода родительского типа попасть назад в дочерний.

плутать по композиционной лапше (это тот самый «индусский код»?)

Код запутывает не использование композиции, а неправильное использование абстракций

ООП наследование при правильном использовании абстракций сокращает количество кода, а значит и упрощает его откладку и потенциальное количество багов?

Я отвечал на часть про лапшу и имел ввиду любой язык. Другой пример: передача объекта с HTTP-параметрами в тип для запроса пользователя из бд.

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

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

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

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

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

до создания иерархии классов обычно относительно долго и тщательно опрашиваю по поводу содержимого ТЗ, нередко сам его дорабатываю с подтверждением доработок ТЗ у клиента ессно.

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

Execution of statements at run time tends to jump around in different mixins, making it hard to follow and debug

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

Potential for long compile times

Го создавался с целью быстрых компиляций. Пока что встраивание типов не мешает.

Increased dependencies

It is unclear how to invoke base class constructors, there is a tendency to use the two stage construction pattern

Не понял, к сожалению.

О каких «подразделениях» речь?

Subdivision. Есть концепция «животное», а «рыба» — подразделение. Перевёл как смог.

Допустим, у нас есть объект с HTTP-параметрами и в определённом месте работа с ним становится настолько однородной, что появляется возможность создать тип «запрос финансового отчёта». Когда мы создаём подразделения концепций в реальной жизни (животное → рыба), то новые концепции сохраняют существенную характеристику родительской концепции, но она либо сужается, либо дополняется новыми характеристиками. В программировании на ум, конечно, приходит полиморфизм, когда мы можем в любой момент использовать «запрос финансового отчёта» как «HTTP-запрос».

Но это не одно и то же. Для ОО-стиля важен сам факт подразделения, а полиморфизм — это просто возможность символа представлять несколько разных типов. Если нам придётся вместо send(finRequest) использовать send(finRequest.Original), то ничего плохого не случится.

В Го, кстати, описанный пример возможен. Но, в отличие от наследования, мы не можем из кода родительского типа попасть назад в дочерний.

плутать по композиционной лапше (это тот самый «индусский код»?)

Код запутывает не использование композиции, а неправильное использование абстракций

ООП наследование при правильном использовании абстракций сокращает количество кода, а значит и упрощает его откладку и потенциальное количество багов?

Я отвечал на часть про лапшу и имел ввиду любой язык. Другой пример: передача объекта с HTTP-параметрами в тип для запроса пользователя из бд.

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

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

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

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

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