История изменений
Исправление sanyo1234, (текущая версия) :
В программировании обобщения реализуются с помощью интерфейсов, open-close-read-write. Подразделения зачастую просто просто описываются как «файл блочного устройства», «файл сетевого устройства». Когда для подразделения нужен новый тип, то ты просто вводишь новый тип, элемент наследования вовсе не обязателен.
О каких «подразделениях» речь? Это выхлоп АИ или неудачный перевод с иностранного языка?
Код запутывает не использование композиции, а неправильное использование абстракций («пойду на рыбалку ловить животных на маленькую змею»).
Какой-то бред. ООП наследование при правильном использовании абстракций сокращает количество кода, а значит и упрощает его откладку и потенциальное количество багов?
Про принцип composition over inheritance ещё можешь читнуть в Design Patterns, но я лично не читал.
Да читал я, но не зацепило совсем, какая-то примитивизация ради снижения порога входа на том, на чём IMHO снижать не стоило бы. Вход - рупь, выход - десять. Golang хорош для корпораций, чьи кошельки могут нанять 100500 кодеров для поддержки всего этого композиционного лапшекода. Вероятно для снижения безработицы среди недорогих вкатунов и чтобы саппортить относительно крупные проекты могли только богатые конторы с большим штатом кодеров, своеобразная искусственная деформация рыночка с использованием композиционных «инноваций».
Исправление sanyo1234, :
В программировании обобщения реализуются с помощью интерфейсов, open-close-read-write. Подразделения зачастую просто просто описываются как «файл блочного устройства», «файл сетевого устройства». Когда для подразделения нужен новый тип, то ты просто вводишь новый тип, элемент наследования вовсе не обязателен.
О каких «подразделениях» речь? Это выхлоп АИ или неудачный перевод с иностранного языка?
Код запутывает не использование композиции, а неправильное использование абстракций («пойду на рыбалку ловить животных на маленькую змею»).
Какой-то бред. ООП наследование при правильном использовании абстракций сокращает количество кода, а значит и упрощает его откладку и потенциальное количество багов?
Про принцип composition over inheritance ещё можешь читнуть в Design Patterns, но я лично не читал.
Да читал я, но не зацепило совсем, какая-то примитивизация ради снижения порога входа на том, на чём IMHO снижать не стоило бы. Вход - рупь, выход - десять. Golang хорош для корпораций, чьи кошельки могут нанять 100500 кодеров для поддержки всего этого композиционного лапшекода. Вероятно для снижения безработицы среди недорогих вкатунов и чтобы саппортить могли только богатые конторы, своеобразная искусственная деформация рыночка.
Исправление sanyo1234, :
В программировании обобщения реализуются с помощью интерфейсов, open-close-read-write. Подразделения зачастую просто просто описываются как «файл блочного устройства», «файл сетевого устройства». Когда для подразделения нужен новый тип, то ты просто вводишь новый тип, элемент наследования вовсе не обязателен.
О каких «подразделениях» речь? Это выхлоп АИ или неудачный перевод с иностранного языка?
Код запутывает не использование композиции, а неправильное использование абстракций («пойду на рыбалку ловить животных на маленькую змею»).
Какой-то бред. ООП наследование при правильном использовании абстракций сокращает количество кода, а значит и упрощает его откладку и потенциальное количество багов?
Про принцип composition over inheritance ещё можешь читнуть в Design Patterns, но я лично не читал.
Да читал я, но не зацепило совсем, какая-то примитивизация ради снижения порога входа на том, на чём IMHO снижать не стоило бы. Вход - рупь, выход - десять. Golang хорош для корпораций, чьи кошельки могут нанять 100500 кодеров для поддержки всего этого композиционного лапшекода.
Исправление sanyo1234, :
В программировании обобщения реализуются с помощью интерфейсов, open-close-read-write. Подразделения зачастую просто просто описываются как «файл блочного устройства», «файл сетевого устройства». Когда для подразделения нужен новый тип, то ты просто вводишь новый тип, элемент наследования вовсе не обязателен.
О каких «подразделениях» речь? Это выхлоп АИ или неудачный перевод с иностранного языка?
Код запутывает не использование композиции, а неправильное использование абстракций («пойду на рыбалку ловить животных на маленькую змею»).
Какой-то бред. ООП наследование при правильном использовании абстракций сокращает количество кода, а значит и упрощает его откладку и потенциальное количество багов?
Про принцип composition over inheritance ещё можешь читнуть в Design Patterns, но я лично не читал.
Да читал я, но не зацепило совсем, какая-то примитивизация ради снижения порога входа на том, на чём её IMHO снижать не стоило бы. Вход - рупь, выход - десять. Golang хорош для корпораций, чьи кошельки могут нанять 100500 кодеров для поддержки всего этого композиционного лапшекода.
Исходная версия sanyo1234, :
В программировании обобщения реализуются с помощью интерфейсов, open-close-read-write. Подразделения зачастую просто просто описываются как «файл блочного устройства», «файл сетевого устройства». Когда для подразделения нужен новый тип, то ты просто вводишь новый тип, элемент наследования вовсе не обязателен.
О каких подразделения речь? Это выхлоп АИ или неудачный перевод с иностранного языка?
Код запутывает не использование композиции, а неправильное использование абстракций («пойду на рыбалку ловить животных на маленькую змею»).
Какой-то бред. ООП наследование при правильном использовании абстракций сокращает количество кода, а значит и упрощает его откладку и потенциальное количество багов?
Про принцип composition over inheritance ещё можешь читнуть в Design Patterns, но я лично не читал.
Да читал я, но не зацепило совсем, какая-то примитивизация ради снижения порога входа на том, на чём её IMHO снижать не стоило бы. Вход - рупь, выход - десять. Golang хорош для корпораций, чьи кошельки могут нанять 100500 кодеров для поддержки всего этого композиционного лапшекода.