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

если что, тегайте меня, я поотвечаю потом

Это фраза которую все запоминают и дальше неё не читают. "А, тут и так всё понятно"

тип того. Вот лисков слоооожна

многабукав

на самом деле вся соль SOLID в open/close. В этом ключе SRP лишь позволяет лучше добиваться open/close а остальные три больше про способы как его делать и проверять на адекватность

а соль open/close - "добавлять/менять поведение не меняя код". Опять же вполне конкретный принцип с конкретными примерами (плагины в IDE, боты в телеграме или слэке)

protected variations из grasp один в один open/close. Но вокруг другие принципы - чуть попроще (например information expert и coupling/cohesion существенно проще в восприятии)

p.s. а еще можно просто почитать оригинал у того же дяди боба про принципы проектирования объектно ориентированных штук. Мол ДО того как кто-то подсказал ему сделать SOLID и оставить только 5 из 11-ти принципов

а еще можно википедию жахнуть. Думаешь люди не умеют в гугл?

думаю умеют.

но удобно когда ссылка под рукой.

все это все просто "переосмысление" идей Парнаса :) тобишь им уже лет 40-50

information hiding оч красиво мэпится на open/close + srp или тот же protected variations

вообще забавно... люди узнают про SOLID и думают что этого хватит.... Хотя даже у того же дяди Боба в книжке солид было лишь главой...

Можно почитать идеи Ребекки Вирсбрукс (Rebecca Wirfs-Brooks) у которой по сути SRP дядя Боб и слизал. Можно почитать Эванса и его эти bounded contexts. Можно почитать Дэвида Парнаса и его "критерии декомпозиции програмных систем", можно почитать Teams Topologies, можно почитать Кокберна с его архитектурой портов и адаптеров.

Все эти идеи связаны между собой.

мне оч понравилось у Альберто Брандолини в его недописанной книжке про event storming на тему того "что такое software system" (похожие мысли можно у Джефа Паттона найти, который про user story mapping*). Мол что проблема в том что "что делать" никто не знает, есть "что за проблему надо решить" и это можно узнать и есть разные аспекты решения. И "как лучше" обычно знают разные люди, потому и важны все эти cross functional teams.

ладно меня понесло

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