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

Правильное использование наследования это как правильное использование goto.

Правильное использование goto тривиально: выход из 2-х и более вложенных циклов.

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

Тут я с вами соглашаюсь. Вот по этому классов и наследования нет в Golang.

Наследование не помогает бороться со связностью, а наоборот порождает её.

Формально да. По сути нет. Связность (coupling) это когда один объект «знает» о способе функционирования другого объекта. Страница 37: Coupling Between Objects (CBO); POODR (c) Sandi Metz.

Наследование помогает достичь Single Responsibility, бороться с Multiple Responsibility, что может трактоваться как максимальная степень Strongly Coupling. Multiple Responsibility — это Strongly Coupling. Все связано в одном месте.

Дело не в связности (coupling) как таковой, а в её степени: loosely/strongly coupled. Хотя в разговорной речи связность часто понимается в негативном ключе как strongly coupled code.

Листал POODR, гуглил лекции, не хочется стирать. По существу, все верно, но можно начать придираться к терминологии: где Single Responsibility, а где Open/Closed Principle.

Связность (сoupling) и связи (connections) это разные термины, сильно созвучные в русском языке.

Вот мое объяснение, принципа Open/Close в SOLID, и то как он помогает избежать cвязность (coupling) через наследование.

«Связность» (coupling) — это не возможность вносить изменения в одну часть программы, не задев другую. Связность порождает хрупкость (fragile): начали менять формат хранения данных с XML на JSON — поломалось подключение к базе данных. Части системы не изолированы друг от друга.
Механизм наследования позволяет изолировать новый слой абстракции. Новый слой абстракции изолирован от предыдущего. Отнаследовали записывать в базу данных, в наследнике XML меняете на JSON, JSON на YAML, YAML на TOML — подключение к базе данных не поломается. Также вы меняете тип сервера в базовом классе, это никак не влияет на формат хранения. Произошло разделение (decoupling): формат хранения отделен от подключения. Связность (coupling) уменшилась.

Убрать связность (coupling) не значит убрать связи (connections); убрать связность значит добавить возможность изменять одну часть программы, не затрагивая другую. Хотя части зависят друг от друга и имеют иерархию.

Правильное использование наследования это как правильное использование goto.

Правильное использование goto тривиально: выход из 2-х и более вложенных циклов.

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

Тут я с вами соглашаюсь. Вот по этому классов и наследования нет в Golang.

Наследование не помогает бороться со связностью, а наоборот порождает её.

Формально да. По сути нет. Связность (coupling) это когда один объект «знает» о способе функционирования другого объекта. Страница 37: Coupling Between Objects (CBO); POODR (c) Sandi Metz.

Наследование помогает достичь Single Responsibility, бороться с Multiple Responsibility, что может трактоваться как максимальная степень Strongly Coupling. Multiple Responsibility — это Strongly Coupling. Все связано в одном месте.

Дело не в связности (coupling) как таковой, а в её степени: loosely/strongly coupled. Хотя в разговорной речи связность часто понимается в негативном ключе как strongly coupled code.

Листал POODR, гуглил лекции, не хочется стирать. По существу все верно, но можно начать придератья к терминологии где Single Responsibility, а где Open/Close.

Связность (сoupling) и связи (connections) это разные термины, сильно созвучные в русском языке.

Вот мое объяснение, принципа Open/Close в SOLID, и то как он помогает избежать cвязность (coupling) через наследование.

«Связность» (coupling) — это не возможность вносить изменения в одну часть программы, не задев другую. Связность порождает хрупкость (fragile): начали менять формат хранения данных с XML на JSON — поломалось подключение к базе данных. Части системы не изолированы друг от друга.
Механизм наследования позволяет изолировать новый слой абстракции. Новый слой абстракции изолирован от предыдущего. Отнаследовали записывать в базу данных, в наследнике XML меняете на JSON, JSON на YAML, YAML на TOML — подключение к базе данных не поломается. Также вы меняете тип сервера в базовом классе, это никак не влияет на формат хранения. Произошло разделение (decoupling): формат хранения отделен от подключения. Связность (coupling) уменшилась.

Убрать связность (coupling) не значит убрать связи (connections); убрать связность значит добавить возможность изменять одну часть программы, не затрагивая другую. Хотя части зависят друг от друга и имеют иерархию.

Правильное использование наследования это как правильное использование goto.

Правильное использование goto тривиально: выход из 2-х и более вложенных циклов.

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

Тут я с вами соглашаюсь. Вот по этому классов и наследования нет в Golang.

Наследование не помогает бороться со связностью, а наоборот порождает её.

Формально да. По сути нет. Связность (coupling) это когда один объект «знает» о способе функционирования другого объекта. Страница 37: Coupling Between Objects (CBO); POODR (c) Sandi Metz.

Наследование помогает достичь Single Responsibility, бороться с Multiple Responsibility, что может трактваться как максимальная степерь Strongly Сoupling. Multiple Responsibility это Strongly Сoupling. Все связанно в одном месте.

Дело не в связности (coupling), а в её степени: loosely/strongly coupled. Хотя в разговорной речи связность понимается в негативном ключе как strongly coupled code.

Листал POODR, гуглил лекции, не хочется стирать. По существу все верно, но можно начать придератья к терминологии где Single Responsibility, а где Open/Close.

Связность (сoupling) и связи (connections) это разные термины, сильно созвучные в русском языке.

Вот мое объяснение, принципа Open/Close в SOLID, и то как он помогает избежать cвязность (coupling) через наследование.

«Связность» (coupling) — это не возможность вносить изменения в одну часть программы, не задев другую. Связность порождает хрупкость (fragile): начали менять формат хранения данных с XML на JSON — поломалось подключение к базе данных. Части системы не изолированы друг от друга.
Механизм наследования позволяет изолировать новый слой абстракции. Новый слой абстракции изолирован от предыдущего. Отнаследовали записывать в базу данных, в наследнике XML меняете на JSON, JSON на YAML, YAML на TOML — подключение к базе данных не поломается. Также вы меняете тип сервера в базовом классе, это никак не влияет на формат хранения. Произошло разделение (decoupling): формат хранения отделен от подключения. Связность (coupling) уменшилась.

Убрать связность (coupling) не значит убрать связи (connections); убрать связность значит добавить возможность изменять одну часть программы, не затрагивая другую. Хотя части зависят друг от друга и имеют иерархию.

Правильное использование наследования это как правильное использование goto.

Правильное использование goto тривиально: выход из 2-х и более вложенных циклов.

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

Тут я с вами соглашаюсь. Вот по этому классов и наследования нет в Golang.

Наследование не помогает бороться со связностью, а наоборот порождает её.

Формально да. По сути нет. Связность (coupling) это когда один объект «знает» о способе функционирования другого объекта.

Наследование помогает достичь Single Responsibility, бороться с Multiple Responsibility, что может трактваться как максимальная степерь Strongly Сoupling. Multiple Responsibility это Strongly Сoupling. Все связанно в одном месте.

Дело не в связности (coupling), а в её степени: loosely/strongly coupled. Хотя в разговорной речи связность понимается в негативном ключе как strongly coupled code.

Листал POODR, гуглил лекции, не хочется стирать. По существу все верно, но можно начать придератья к терминологии где Single Responsibility, а где Open/Close.

Связность (сoupling) и связи (connections) это разные термины, сильно созвучные в русском языке.

Вот мое объяснение, принципа Open/Close в SOLID, и то как он помогает избежать cвязность (coupling) через наследование.

«Связность» (coupling) — это не возможность вносить изменения в одну часть программы, не задев другую. Связность порождает хрупкость (fragile): начали менять формат хранения данных с XML на JSON — поломалось подключение к базе данных. Части системы не изолированы друг от друга.
Механизм наследования позволяет изолировать новый слой абстракции. Новый слой абстракции изолирован от предыдущего. Отнаследовали записывать в базу данных, в наследнике XML меняете на JSON, JSON на YAML, YAML на TOML — подключение к базе данных не поломается. Также вы меняете тип сервера в базовом классе, это никак не влияет на формат хранения. Произошло разделение (decoupling): формат хранения отделен от подключения. Связность (coupling) уменшилась.

Убрать связность (coupling) не значит убрать связи (connections); убрать связность значит добавить возможность изменять одну часть программы, не затрагивая другую. Хотя части зависят друг от друга и имеют иерархию.