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

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

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

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

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

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

Наследование помогает бороться с Single 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.

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

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

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

Листал POODR, гуглил лекции, не хочется стирать. По существу все верно, но можно начать предератья к терминологии где Single Respnsibility, а где 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.

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

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

Листал POODR, гуглпл лекции, не хочется стирать. По существу все верно, но можно начать предератья к терминологии где Single Respnsibility, а где 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.

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

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

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

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

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

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

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